E9.2 How to make a SREQ recording return errors if recording clicks Find and clears errors (P4617 Confirm > Process)

[JohnDanter2]

Hi all

I have a very tricky one (again ) in that my recording of me confirming warehouse suggestions in P4617 W4617B has 3 steps.
1) First you enter your data in the QBE click Find
2) Highlight the row then click Confirm (this calls an edit line BSFN and loads cache) *** Importantly throws errors on the screen in this step ***
3) Then you click Process (this actually clicks Find then executes the End Doc if no errors found - it clears out any errors by clicking Find)

The trouble is if there is anything wrong in steps 1 and 2 and any errors were thrown (LOTN on hold for example) when you click Process in step 3 the code clicks Find and therefore wipes any errors. So the consuming code never knows there was an error thanks to step 3

Is it possible to split the SREQ recording into 2 main SREQs, one containing steps 1 and 2 and then step 3 (Process) in a sepearate step.
I am hoping that I can split the form recording into 2 but something tells me I'd need to reload all the data back into the second SREQ if there were no errors







Thanks

John

 

[DaveWagoner]

I've had.... "mixed" results trying to split Form Reqs into separate entities. Sometimes it seems to work, sometimes it crashes and burns. We have some moving pieces involving upgrading so my env isn't necessarily a good one to prove/disprove this thought. I'd say to give it a shot and see what happens.

 

[Kevin Long]

One option you might consider is using the Application Stack Server API that is available on the AIS server. This service is a REST api that you can call from a connector to the local AIS server. You cannot use the process recorder to create the form request. It is all done by posting JSON to the API which can be tedious. However, when you perform an action on the form, you get a JSON response back that you can use to determine that you want the next step in the orchestration to do. I use this API whenever I need to control the next action based what the form returns based on the last call, or when I need to batch a bunch of changes on a single document and save it once. The documentation on the API is available here: https://docs.oracle.com/en/applicat...2/rest-api/api-application-stack-service.html. This does require a string comfort level building and manipulating JSON using script. However, it does provide a much more granular level of control over the form versus using a standard form request.

 

[JohnDanter2]

One option you might consider is using the Application Stack Server API that is available on the AIS server. This service is a REST api that you can call from a connector to the local AIS server. You cannot use the process recorder to create the form request. It is all done by posting JSON to the API which can be tedious. However, when you perform an action on the form, you get a JSON response back that you can use to determine that you want the next step in the orchestration to do. I use this API whenever I need to control the next action based what the form returns based on the last call, or when I need to batch a bunch of changes on a single document and save it once. The documentation on the API is available here: https://docs.oracle.com/en/applicat...2/rest-api/api-application-stack-service.html. This does require a string comfort level building and manipulating JSON using script. However, it does provide a much more granular level of control over the form versus using a standard form request.

Awesome thanks Kevin

That actually looks like the first ever AIS type thing E1 came out with, right? You build the request steps yourself in the JSON and fired it off. Good idea.
I can't see my .NET team going for this but it is good to know we could do it this way yes

You're the same Kevin Long with that awesome excel API???

 

[jolly]

One approach Is to use a form request just to do the find, setting the “return raw output” option. Then inspect the returned json in a groovy request to determine if the row is present. If so, proceed with the full process in your original form request.

 

[JohnDanter2]

One approach Is to use a form request just to do the find, setting the “return raw output” option. Then inspect the returned json in a groovy request to determine if the row is present. If so, proceed with the full process in your original form request.

I like that yes, thanks

 

[jolly]

I like that yes, thanks

There's another even more important use for this method: you can return the row number of a headerless detail grid that matches some criteria. As these grids are not QBE filterable you need to know which row number a record is in if you are subsequently going to update data in there, using the SelectRowForUpdate action in your FormRequest step.