There's not a lot that needs doing ... you need to update the connection information in appsrvtt.d (to use the -URL syntax). Make sure that the PROPATH in PASOE points to the right place.
And that is just about it.
JsonObjects are 11.0 and later. I think (per History of Progress Versions | The OpenEdge Hive) that WRITE-JSON on temp-tables and ProDataSets was 10.2B. If you can use those depends on whether the required data is in a "dataset format".
As @Hikmet_Alemdaroglu says, writing JSON isn't that hard...
The temp-table and dataset WRITE-XML (and WRITE-JSON) methods write out the entire contents of the dataset/temp-table.
You would call SERIALIZE-ROW on the buffer, so the syntax would be BUFFER tt_woorder:SERIALIZE-ROW(...) . YOu will overwrite the file each time you call it, so I would write...
This sounds familiar ... Given that the "static class" - or more accurately, a class with static members - is loaded into memory once and held there for the life of the session, there's now an rcode reference to the Config table and so, I think, the DB connection is not actually fully...
Are there any useful errors in the agent log? Or the session manager (aka dated) log?
There have been bugs in the session manager code where agents are left in a zombie state (cannot process any more requests, but don't remove themselves from service) and eventually the server stops responding...
It will persist in a single AVM session (so Classic agent/client session/etc, or a single session in a PASOE multisession agent process). The "global" nature of shared things means that it's not limted to the current call stack, but the whole AVM session can access that thing (variable...
I am not advocating for using _User, but you can mitigate matters. You can use the OE Authentication Gateway (since 11.6.something) to add better authentication - using Active Directory or LDAP or something - and not have to manage credentials, their storage and their policies.
That said, if...
As much as the thought of using global shared temp-tables makes me throw up in my mouth a little bit, having such a beast have the same name as the db table is a neat trick, and should let you implement "common.i" incrementally throughout the application.
Put it in -B2 ? And let it churn away.
You can cache the data in static OOABL members (properties/whatever). Add a "last loaded" timestamp too, and maybe a "max age" value.
In the activate procedure - and if that doesn't run for Classic WebSpeed, there's a procedure named something like...
Are you calling the SOAP service yourself? Or is this just an XML file that you are being asked to process?
If a SOAP service: if you have a WSDL for the SOAP service, you can use the $DLC/bin/bprowsdldoc script to generate documentation on the WSDL, including ProDataSet definitions.
You really don't need to do this.
input from value(file-info:file-name) binary no-map no-convert.
copy-lob from vmfile to vlcfile.
You can just use COPY-LOB to read the file directly ...
copy-lob from file file-info:full-pathname to vlcFile.
Possibly. You need the Subject, not the issuer, though.
So, get ASN.1-encoded subject.
SHA-1 hash it (into a big-endian-byte-order memptr).
Hex-encode the first 4 bytes .
(edit: had to /.-ify this post)
It appears to be a tad involved.