SBA is not as Asynchronous as you might think

This article was originally published from https://winthropdc.wordpress.com/2016/03/09/sba-is-not-as-asynchronous-as-you-might-think/

Service Based Architecture (SBA) was released with Microsoft Dynamics GP 2015, it covers technologies to make Dynamics GP more accessible to external applications by allowing Dexterity global procedures to be exposed as Web Services. It also allows Dexterity code to directly access and use .Net objects via the .Net Interop.

SBA opens up an entire new world of development opportunities.

As you might have noticed, in the last few days I have posted articles relating to Web Services using Service Based Architecture and the Batch Posting Service Toolkit (BPST).

There is a reason…. I have been working with Neal Santin from WebSan Solutions to implement BPST on their systems. Neal has been a great help to work through some of the issues we found and his assistance is appreciated. He told me of a new issue that he has come across which is the subject of this article.

When they started using BPST to post batches, they found that if they make the web service calls too quickly they would receive a 403 (forbidden) error with the description:

403 – The specified user is not authorized to perform operations in this context

The issue is that the web service call uses credentials to log into a specific user and company of Dynamics GP. Once the web service finishes processing it logs out. As is the same with the full Dynamics GP client you can only log in once for a specific user and company combination.

So if you try and log in again before the web service has finished, you will get the above error message. This issue will be worse on web service calls that take longer to process, such as posting. The issue was that they were generating web services calls faster than Dynamics GP’s ability to process them.

I did double check with my friend Brian Roney at Microsoft and he confirmed that you cannot call a web service using same user until the previous call had completed:

If a call is still processing for a user that user cannot successfully make another call until the first one finishes.

Once Neal and his team worked out the cause of the error they implemented a retry loop to pause and try again if they received a 403 error. However, this method meant staying single threaded (same user and company) and a backlog of web service calls could easily build up.

To get around the issue, Neal came up with the second part of the solution to use a pool of User IDs in rotation so that multiple web service calls can be processed concurrently. Creating additional Active Directory (AD) users and linking them to different GP User IDs allowed for multiple web services calls to launch multiple instance of the runtime engines used for processing SBA web services.

Moral: If you are planning to make heavy use of web services using a single User ID to make the calls, be aware that you might hit this 403 error issue and need to implement some workaround solutions.

Moral 2: A 403 error could just mean that the User ID and Company ID you are trying to use is currently logged into Dynamics GP.

Thanks to Neal for letting me share his experiences.

Hope you find this helpful.

David