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
This article was originally posted on http://www.winthropdc.com/blog.
Winthrop Development Consultants Blog 
Thanks for sharing that David. SBA is great, but we’re running into some challenges ourselves. In our case we would like to use it for integrations between other systems. We can’t do that with concurrent licences. When all licences are in use from people logged in or from orphaned sessions then the integration can’t log into GP either. The error returned isn’t even clear as to why. Technically we understand why this is happening.
A desktop user can log into the system in the morning and be confident that they can use the system for the rest of the day. SBA logs in and out during each call, so it’s a gamble as to whether the service will be available making the integration seem unstable.
This happens for our own SBA methods that we developed for our 3rd party dictionaries. We are still figuring out how to licence this technology to unlock its potential.
LikeLike
Hi Wes
You might have to create a user account (or 2) for use with SBA. One that would not be used by your users.
I will chat to my contacts in Microsoft and asked about the licensing side of using SBA.
David
LikeLike
Thanks David. We did create user accounts for SBA that weren’t used by other users. They were full users. In our case the site allowed 15 concurrent logins and 15 desktop users happened to be logged in. When an SBA call was made it didn’t allow the SBA call to be made because the max number of users had been reached, even though the SBA user wasn’t already logged in. We would buy another user to allow 16, but that doesn’t guarantee that another desktop user won’t jump in and use it.
LikeLike
I’m making several SBA calls to create several bills in GP. For example I’m creating 500 bills, and most of the time, they work flawlessly.
But sometimes maybe the first 200 will work, but the remaining 300 will get that 403 error.
Is that really an issue of making SBA calls too quickly, or something breaking or locking up?
LikeLike
Hi Zane
Yes, that sounds exactly like the problem. Try adding a pause, or alternating User ID used, or retrying when you get a 403 error.
David
LikeLike