Skip to main content
Solved

The request channel timed out while using ODATA REST API

T
Sidekick (Customer)
Forum|alt.badge.img+8

We have recently upgraded to FSM 6UPD9 to make use of the ODATA REST APIs in order to integrate our external applications with FSM. 

Very often we are getting a request channel timeout while using the ODATA REST API’s. Once this starts every call fails. 

Message:Error occurred while getting EDM model from app server.
System.TimeoutException: The request channel timed out while waiting for a reply after 00:00:59.9970047. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.

 

The ODATA rest API's makes a call to the FSM server "<perform_get_updated_odata_edm>" to get the data model. It basically asks for the database table structure of ~1200 tables in FSM, which looks to be a very time-consuming operation. We have observed that the ODATA API attempts to refresh the EDM model every time there is a server restart/ IIS reset or whenever we do a refresh cache (full) from FSM smart client. The refresh cache is something we are doing every time we make any change using the FSM smart client.

Anyone else experiencing the same ? and is there any fix /workaround to this? 

Best answer by Saranga Amaraweera

Hi,
Information from R&D : what they said was in the first service call, it requests metadata from server to build the EDM model.  Hence, getting the metadata from the application server takes a bit of time. Also as per the comments, there was a bug in which they have fixed it on update 11. They are doing furthermore enhancements to improve the performance on the OData API calls.

Workaround:

If you’re using FSM on premise, then you may go to OData API application pool in IIS and go to the advanced properties of the application pool. Then set the start mode as AlwaysRunning instead of OnDemand (which is the default mode)

 

Also set the idle timeout setting as 0 instead of 20 minutes.

 

If your installation is in the cloud then, the application pool has to be with the correct setting, but your workaround could also work based on the schedule to keep it warm. You might be able to check the idle timeout if you have access to cloud server configuration. 
 

View original

S
Superhero (Employee)
Forum|alt.badge.img+21

Hi Sourabh,

This issue is fixed in UPD14.

 

Saranga Amaraweera
Superhero
Forum|alt.badge.img+22

Hi @TDCSOURABH ,

You may need to take a look at this post. There’s a workaround for UPD9 but as @Sajith Anushan  mentioned, this issue has been resolved in UPD14

https://community.ifs.com/ifs-field-service-management-fsm-employees-partners-only-103/fsm-odata-rest-api-first-call-after-inactivity-is-slow-9874?postid=35625#post35625

 

SAAALK
T
Sidekick (Customer)
Forum|alt.badge.img+8
  • TDCSOURABH
  • Sidekick (Customer)
  • November 25, 2021

Hi @Saranga Amaraweera , 

It  looks to be a restricted content.

Can you provide more details regarding the workaround? 

 

 

--

Sourabh Jain

Saranga Amaraweera
Superhero
Forum|alt.badge.img+22

Hi,
Information from R&D : what they said was in the first service call, it requests metadata from server to build the EDM model.  Hence, getting the metadata from the application server takes a bit of time. Also as per the comments, there was a bug in which they have fixed it on update 11. They are doing furthermore enhancements to improve the performance on the OData API calls.

Workaround:

If you’re using FSM on premise, then you may go to OData API application pool in IIS and go to the advanced properties of the application pool. Then set the start mode as AlwaysRunning instead of OnDemand (which is the default mode)

 

Also set the idle timeout setting as 0 instead of 20 minutes.

 

If your installation is in the cloud then, the application pool has to be with the correct setting, but your workaround could also work based on the schedule to keep it warm. You might be able to check the idle timeout if you have access to cloud server configuration. 
 

SAAALK
T
Sidekick (Customer)
Forum|alt.badge.img+8
  • TDCSOURABH
  • Sidekick (Customer)
  • November 25, 2021

Hi, 

Thanks a lot.

Does setting start mode to “AlwaysRunning” ensures that the refresh EDM model is automatically invoked after the full server restart or will it wait for the 1st API call. 

And setting idleTimeout to 0 will ensure there are no automatic pool restarts, but how does it behave with full server restarts or refresh cache from FSM client. 

 

-- 

Sourabh Jain 

 

 

 

 

Saranga Amaraweera
Superhero
Forum|alt.badge.img+22
TDCSOURABH wrote:

Hi, 

Thanks a lot.

Does setting start mode to “AlwaysRunning” ensures that the refresh EDM model is automatically invoked after the full server restart or will it wait for the 1st API call. 

And setting idleTimeout to 0 will ensure there are no automatic pool restarts, but how does it behave with full server restarts or refresh cache from FSM client. 

 

-- 

Sourabh Jain 

 

 

 

 

Only the very first call in the pool might take a bit of time to load the full EDM model  (similarly a cold start) and then setting always running property in the app pool will keep the connection warm so that it would not require to load the EDM model for ongoing requests. Refresh cache on FSM client happens actually in the fsm application pool and it’s not dependent with the Odata app pool

SAAALK
T
Sidekick (Customer)
Forum|alt.badge.img+8
  • TDCSOURABH
  • Sidekick (Customer)
  • November 25, 2021

Hi, 

Ok, so it is not automatic we have to manually trigger the first call after full server restarts to ensure the reload of EDM model and then the always running property will kick in to keep the connections warm. 

 

We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls  also behaves same, they time out and  starts working after ~5-10 mins 

 

--

Sourabh Jain

 

T
Sidekick (Customer)
Forum|alt.badge.img+8
  • TDCSOURABH
  • Sidekick (Customer)
  • December 2, 2021

“We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls  also behaves same, they time out and  starts working after ~5-10 mins ”

 

Same behavior when doing “Refresh Cache” as well. 

 

--

Sourabh Jain

Saranga Amaraweera
Superhero
Forum|alt.badge.img+22
TDCSOURABH wrote:

“We have seen that whenever we do Refresh Cache (full) from FSM smart client then after the API calls  also behaves same, they time out and  starts working after ~5-10 mins ”

 

Same behavior when doing “Refresh Cache” as well. 

 

--

Sourabh Jain

Hi @TDCSOURABH ,

Have you tested the same with the given settings above?

SAAALK
T
Sidekick (Customer)
Forum|alt.badge.img+8
  • TDCSOURABH
  • Sidekick (Customer)
  • December 7, 2021

Hi,

Yes, It is same after changing the above settings. 

--

Sourabh Jain

Ann Degroat
C
2 people like this
  • Ann Degroat
    Ann Degroat
  • C
    cgkougkoul

Reply


Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings