Maintaining job id through multiple webservice calls

Question

Question

Ben Anderson · Sep 23, 2020

I've run into an issue where job IDs are being retained through multiple calls. My team is doing a rewrite of our system that allows VB6 apps and web apps to directly interact with our Cache databases.

The new process has those applications calling into a WebAPI which then calls into the routines.

In one example of the issue we're having, the VB6 app calls into our api which then does the routine call. The Cache routine I'm working with has a load linetag that loads data into a temporary global called ^SORT($J). Upon completion, the process returns back through the api and the VB6 app. When the user decides to perform a Save, the app again calls into the api and then to another linetag of that routine that attempts to loop through ^SORT($J). The problem is that the 2nd call is coming in with a different job ID and therefore it can't see ^SORT($J from before and now we have bad data.

Is there any way to maintain a job ID through multiple calls like this? Before we moved to Cache, this app (and many others) worked as it maintained the state. Thank you!

Discussion (2)0

Log in or sign up to continue

Robert Cemper · Sep 23, 2020

Depending on how you have built your WebAPI every request may run its own session with its own job id.
CSP has the concept of a SessionID to bypass such problem.
But it requires that you pass the Id back to the client and clean it up once done.

You may follow this philosophy using a random unused key [ $D(^SORT(key))=0 ] instead of $J that you pass back to the client.
Cleaning it up is a good practice to avoid to much waste in your global. [ BTW. also with $JOB ]

1 0

score 0 · Answer 1 · 2020-09-28T13:00:27-04:00

Eduard Lebedyuk · Sep 28, 2020

Use session id to track data between calls.

In general I would suggest moving to REST stateless architecture.

0 0