The Application Stack Service is an API on the AIS server. What the appstack service gives you is complete control of an interactive application. Basically, it allows you to dynamically create your form request as you work your way through whatever it is you are trying to accomplish. You access it using a REST connector as a Local AIS Call. Every call goes to the same API, but the json will be different. Generally, the first call you make to API is to open the stack. Then you will perform a number of actions to complete some work, and finally, you will close the stack. The API’s response will tell you what is on the screen, including warnings and errors. You can parse that response in Ruby or Groovy, and dynamically create your next ActionRequest depending what was returned from the previous call.
I use the api whenever the steps in a form request are not repeatable (a sales order with some kit items mixed would be one potential example), require a lot of extra steps to look up information before calling a form request, or if I want to leverage the form to validate my data and give me an opportunity to fix an error. It is important to note that unlike a form request that will throw an orchestration error if the JDE application throws an error, the api will simply return the error. This means you need to be mindful that you are building your own error handling. However, that kind of control can be really helpful.
Here are a couple of examples where I used the API:
A client wanted an orchestration to upload p-card transactions from a flat file provided by their bank into AP vouchers. I used appstack api to load the data into the P0411Z1, and then capture the errors found when the P0411Z1 tried to save. Most of the errors were bad subledgers or gl accounts, and I could “fix” the errors by using default values provided by the business so that the transactions could be saved. Then I could produce an error report of the changes I made. This gave the AP to go back to the source system and fix it. However, if they were coming up on a payment run they could load the vouchers as is, and create journal entries to correct the expense afterwards.
Another client needed to make last minute changes to sales orders (additions, substitutions, deletes) just before they released them for picking based on inventory availability. Normally there would be multiple changes on a single sales order. With the api I was able to open the sales order, retrieve the detail lines, determine what changes were required to the order, create the json to adjust the order, make the change, and save the order once. The client did the first iteration of the orchestration using form requests and it took several hours to process all of their changes. Using the API, we were able to get it under an hour simply because we able to remove a lot of data requests and rules, and incorporate it into a groovy script. When processing hundreds of orders at a time, that kind of overhead really adds up.
The examples in the Oracle documentation give you some basic json that you can use as a template for your own orchestration. Their examples are called from cURL and include a token. You don’t need to worry about the token when calling from a REST Connector.
Normally, I write my open and close stack connectors first. That way I don’t have to worry about a reservation hanging around when I’m creating the rest of the steps. I create orchestration variables for stackId, stateId, and rid. These three values are returned from the api on each call, and need to be passed into the next call.
If you have any additional questions, please let me know.
