I recommend locking as a solution to that problem.

Create a table/class/global which holds {filename, lock, ownerJobId}.

All service jobs execute the same file search, take first filename, check the lock table. If it's empty - write into it and start processing the file.

If lock table has the entry take the next file, till you find one without lock.

After file is processed delete/move it and remove the entry from lock table.

On job shutdown purge the table records associated with job id.

This way you can scale jobs easily.

You get this error (Datatype value '2019-02-01' is not a valid number) because %Date stores data in horolog format, so you need to do one of:

  • (Recommended approach) Convert date value from external format (2019-02-01) into internal format (horolog) using $zdh function:
Set consumerRecord.ActivePeriod.StartDate = $zdh(obj.activePeriod.startDate, 3)
  • Use datatype for which this value is valid, i.e. %TimeStamp. To check, all datatype classes offer IsValid method, you can use it to check value validity
zw ##class(%TimeStamp).IsValid("2019-02-01")
  • If you're using InterSystems IRIS you can store dates as %PosixTime.

Regarding Atelier, I use it to debug REST services and it shows variable values. You can try to reinstall it. If you're on Windows you can also use Studio.

What does this output in a terminal:

set respText="{""access_token"":""4SDFDSFDSF-aSDASDASD"",""expires_in"":""3300"",""refresh_token"":"""",""scope"":""sms_send"",""token_type"":""Bearer""}"  
set sc = ##class(%ZEN.Auxiliary.jsonProvider).%ParseJSON(respText,,.pObject,1)
zw pObject

I tried it on a later verison and got:

pObject=<OBJECT REFERENCE>[1@%ZEN.proxyObject]
+----------------- general information ---------------
|      oref value: 1
|      class name: %ZEN.proxyObject
| reference count: 2
+----------------- attribute values ------------------
|           %changed = 1
|%data("access_token") = "4SDFDSFDSF-aSDASDASD"
|%data("expires_in") = 3300
|%data("refresh_token") = ""
|     %data("scope") = "sms_send"
|%data("token_type") = "Bearer"
|             %index = ""
+-----------------------------------------------------

That is a fairly common problem - the need to compare two different codebases. It could be a test and prod server or just different production servers. Anyway I usually compare them like this:

  1. Install source control hook (I prefer cache-tort-git udl fork but any udl based will do) on all affected servers.
  2. Export everything from the base server (with oldest sources) using source control hook into a new repostory.
  3. Commit this state as an initial state.
  4. Clone the repository with initial state to the other server.
  5. Export everything from the other server into the repository.
  6. Commit again (if you have more than two parallel codebases you may need to branch out).
  7. Use any commit viewer to see the difference (I prefer GitHub/GitLab).

Is that a production instance?

Is that 8bit or Unicode instance?

What I/O tables NLS routine shows? (Note that modifying locales/defaults can be potentially application-breaking change so do it only if you know what you're doing)

zn "%SYS"

do ^NLS
 
 
1) Display current locale
2) Select defaults
3) Change locale
4) Display loaded settings
5) Advanced
 
NLS option? 2
 
1) Internal tables
2) I/O tables
3) CSP files
4) Date, time and number formats
 
Category of defaults? 2
 
Items marked with (*) represent the locale's original default
 
I/O table              Current default
---------------------  --------------------
 
1) Process             RAW (*)
2) Cache Terminal      UTF8 (*)
3) Other terminal      UTF8 (*)
4) File                UTF8 (*)
5) Magtape             UTF8 (*)
6) TCP/IP              RAW (*)
7) System call         RAW (*)
8) Printer             CP1251 (*)