Jiwa REST API Login Call Response Time.

[sunad]

Hi Mike, Stuart and all others,

We have integrated two systems, Jiwa and Salesforce.
There is an issue now when we have gone live with this project.

Sometimes the Jiwa Login API call gives a response after 10 seconds.
This is something which Salesforce doesn't support.
It waits for a response, and if within 10 seconds it doesn't get one then gives an error called as Read Timed out.

Now, this very rarely happened on the web service hosted for the sandbox, and even for production web service, it didn't happen for around first 200 login API calls.
But after that, it was more frequent and we were not able to get the Frist time Data sync from Jiwa to Salesforce.

Are there any ways that the login response time can be shortened??
Does that depend on the web service hosted?

More info- We started the process at around 6 pm AST and was working great for around 4 hours and then the response time was more than 10 secs for most of the login calls.

We need solutions so that we can ask the responsible team to work on it.

Thanks

[Mike.Sheen]

Hi Sunad,

Understanding what happens when a login request is made is going to help here.

When a login request is made, if no current session is present, we perform our normal login process - and the most expensive part of that is building the plugin cache and loading those.

If there is no current session in the API for the user/API Key when a login is performed, we examine the enabled plugins in the database and compare the hashes against those stored in the ProgramData/Jiwa Financials folder. If the plugins have been modified since the last time the login was made, we compile the source code and write the assemblies away to the ProgramData/Jiwa Financials folder - this can be an expensive operation, but will only happen if the plugin(s) have changed, and the user/API Key does not have a valid current session. Once assemblies are compiled, we then load them into our Appdomain.

Depending on the plugin, some also may have hooks on the Login event and such plugins will execute their respective code - without knowing what plugins you have and what they do, I can't really comment if that aspect is impacting your performance.

If your ProgramData folder is volatile (as is the case when dealing with environments like the Azure App Service - which incidentally we no longer support as of Jiwa 7.2), then you might find the cached plugins will need to be recompiled and loaded upon login, even though they previously were compiled and cached - because the plugin cache has been vaporised by the host - and this would cause latency upon login.

If you can, once a login is established you can keep the session alive to prevent sessions expiring, and thus expensive login operations, by performing a GET on the /KeepAlive route on a regular time interval. By default sessions expire after 5 minutes if no request has been made - but any request made within that 5 minute period will extend the session by a further 5 minutes and not require the login logic to be performed - so we made the /KeepAlive route just for that purpose.

You can also change in Jiwa the default session expiry in minutes from 5 to any value you like.

If you are pushing data from Salesforce into Jiwa's API using their webhooks or similar, then you're likely not handling the scenarios where the Jiwa API is unavailable.

If Salesforce's webhooks have no resilience baked in like Jiwa's own webhooks have, then you should consider a middleware or proxy API to sit in between Salesforce and Jiwa which takes POSTs from Salesforce and queues them to be POSTed into Jiwa - and upon any failure retry based on whatever policy is deemed appropriate.

Mike

[sunad]

Thanks Mike for your help.

[Mike.Sheen]

FYI - We've made some significant improvements with the authentication performance in 07.02.00 SR2. This isn't released quite yet - so there is nothing to download and install yet - but it should be ready in the next 24-48 hours.

We also made it a lot easier to diagnose slow authentication. We added the route /Queries/StartupLog which you can call after authenticating to show where the time was spent during authentication:

Because that route is an AutoQuery, you can obtain the total time it took to authenticate with an aggregate and filter - e.g.: Queries/StartupLog?Depth=1&Include=SUM(ElapsedMilliseconds)
The items of depth 1 are themselves the sum of the items depth 2 occurring afterwards, so by including only items with Depth=1 you get the total logon time.

If you see any plugins being compiled and not just loaded, that indicates the plugin may be failing to compile and will be causing delays on every authentication. Only if a plugin has it's Exception Policy set to Abort is a login prevented if the plugin cannot compile or be loaded - so we added a way to see these exceptions after authenticating by adding a route to list those: /Queries/PluginExceptions.

Once you know which plugin is failing and why - you can then address the issue so the next authentication won't be delayed.