What's Quality area?
It's not a server who checks for expiry, but a client. So your flow works like this:
1. 15:00 calling application runs a GET request for patient?MRN=A2. 15:00 CSP Web application calls HIHLib.REST.Server class and forwards request on to namespace for handling (via business services,process and operations)3. 15:00:05 response is returned with EXPIRES 300 and VaryByParam set to *4. 15:10 a seperate internall process results in patient with MRN A - first name changed from pete to bob5. 15:12 calling application runs a GET request for patient?MRN=A6. 15:12 web browser (on a client side) sees that patient?MRN=A request is cached locally and still valid due to EXPIRES 300. Web browser is returning a cached value to a calling application without going to the server.
And server would never get a second request (that's the point of the EXPIRING header after all).
Expires controls how long the response is valid. It's for things like HTML pages which are static.
If you think that a response can change every time a client requests it, you should not add an EXPIRING header.
Do ..Adapter.%Client.SetHttpHeader(name, value)
set sc = ..Adapter.SetHttpHeader(name, value)
Calling @Benjamin De Boe
If you want to know if a compiled class exists, call:
It, however, does not answer the question of a compiled version being current.
Depends on what WS expects, really.
How about a slightly different architecture:
Advantage of this architecture is that you decouple processing on a namespace level - so if a production in one namespace is in error state/down the rest can proceed. It also eliminates a single point of failure in namespace switching job.
tl;dr instead of pushing your event make consumers pull it whenever convenient.
Supply them in $horolog format. In a case of YYYY-MM-DD, try: $zdateh("YYYY-MM-DD", 3)
Log in or create a new account to continue