Thanks @Patrick Dunn this is indeed a common issue, so thanks for taking the time to post about it.

I was thinking that this might become an even more common issue once we remove our Private Web Server (PWS) [related post for reference] so added this Idea to allow the Web Gateway installer to do this work for you in advance.

@Andreas Dieckow please review (perhaps this was already taken into consideration).
 

Hi @Dmitrii Baranov 
You can take a peak at a similar task performed internally in the FHIR Server REST handler class -

HS.FHIRServer.RestHandler:marshallRequestFromHttp()

    // For compatability, copy all HTTP_ headers into the AdditionalInfo section of the request
    Set tKey = ""
    For {
        Set tKey = $ORDER(%request.CgiEnvs(tKey))
        Quit:tKey="" If tKey?1"HTTP_"1.E {
            // Determine the proper header name (will be all caps unfortunately)
            Set tHeader = $PIECE(tKey,"HTTP_",2,*) // Copy the HTTP headers - except for certain ones.
            If (tHeader '= "AUTHORIZATION") {
                Do pRequest.AdditionalInfo.SetAt(%request.CgiEnvs(tKey), "HEADER:"_tHeader)
            }
        }
    }

Note this is internal code.

You can also similar code for the Generic HTTP Service (used by the Passthrough I mentioned to Alex above), from:

EnsLib.HTTP.Service:addAttributesToBody()

    Set tattrH=$O(%request.CgiEnvs("HTTP_"))
    While $E(tattrH,1,5)="HTTP_" {
        If tattrH'="HTTP_URL",tattrH'="HTTP_VERSION" {
            Set attr=$REPLACE($E(tattrH,6,*),"_","-"), lwrattr=$ZCVT(attr,"L")
            If '((lwrattr="transfer-encoding")&&($ZCVT(%request.CgiEnvs(tattrH),"L")="chunked")),'((lwrattr="content-encoding")&&($ZCVT(%request.CgiEnvs(tattrH),"L")="gzip")) {
                Set:..#TOLOWERHEADERVARS attr=lwrattr
                Set:'$D(lwrattrs(lwrattr)) pStream.Attributes(attr)=%request.CgiEnvs(tattrH), lwrattrs(lwrattr)=""
                Set:"content-length"=lwrattr tLen=pStream.Attributes(attr)
                Set:"content-type"=lwrattr tContentType=pStream.Attributes(attr)
            } ElseIf (lwrattr="content-encoding") {
                Set tgzip = 1ElseIf tLen = "x" {
                Set tLen="xchunked"
            }
        }
        Set tattrH=$O(%request.CgiEnvs(tattrH))
    }

Again this is internal code.

But coming back to my comment to Alex above, I would recommend using one of the approaches I mentioned there (the Generic Passthrough service, or the FHIR Interop. built-in service) and this way all of the above is already handled for you.

Hi @Alex Baumberg !

First, if you just want to send an HTTP Request from one point to another you can use the HTTP Passthrough mechanism.

And see also my comment to Dmitrii's reply below.

In addition if you are focusing on FHIR requests (as I assume you are, per prior knowledge 😉) you can consider using the FHIR Interoperability Adapter mechanism where you will have a "digested" request which already includes all the HTTP Headers in the AdditionalInfo array.

Indeed it is in the Location Header.

From the related FHIR docs:

The server returns a 201 Created HTTP status code, and SHALL also return a Location header which contains the new Logical Id and Version Id of the created resource version:

  Location: [base]/[type]/[id]/_history/[vid]

where [id] and [vid] are the newly created id and version id for the resource version. The Location header should be as specific as possible - if the server understands versioning, the version is included. If a server does not track versions, the Location header will just contain [base]/[type]/[id]. The Location MAY be an absolute or relative URL.

Hi Mark,

Indeed all you need to do with your class/es is extend it/them from the DeleteHelper class. No need to add your own %OnDelete() method (in fact that might interfere with the method generation).

From your comment I cannot tell clearly enough what exactly did not get deleted (or of course why).

Per your question, in general what you can expect to see, as per the example I provided, is that the %OnDelete method (label) gets generated in the generated routine (INT).

If you want you can elaborate a little further about the full structure of your classes (you mention PathologyResult and FreeTextLine, but then later also Location which is unclear how it is related), and data (you just mention some ID numbers, but not really who's who), including message header info, and what you see when you purge the data (messages).

(if you want you can even share the actual classes, if you would prefer, also privately).

Maybe then I can be of more assistance.

Dmitry, following up on @Eduard Lebedyuk's comment, and even though you seem to say IIS is not the cause, this does "smell" like an IIS-related configuration.

I suggest you look here in the IIS docs, and in this related thread.

This setting enables to provide custom error pages instead of the "raw" downstream original server error (to be friendlier to users, or to possibly hide sensitive error details).

Try turning this setting off and see if this helps (if Apache is also available for example you can attempt testing with it as well to compare results).

Following up on Shawn's response, these resources might also be helpful in the meantime, and perhaps for others -

"See how to use key features of the Healthcare Action Engine to set up real-time alerts for clinicians. In this exercise, you will build decision support, design a notification using a CDS Hooks card, and write a rule to deliver it."

[I believe the same comment Shawn mentioned about being required to be a HealthShare customer in order to access this content is relevant here as well.]

I know I'm late to the game, but a few notes I thought were worth mentioning in the context of the question and the discussion here -

1. Re using $sortbegin/$sortend - if you want to take this approach, there are dedicated methods on all %Persistent objects that do exactly this - %SortBegin() and %SortEnd(). Note you can use this per index (or for all) and you don't have to worry about the name of the global etc. So this should definitely be preferred IMHO.

By the way, if you are interested, you can see that the "behind-the-scenes" of %Populate's Populate() method uses this approach (a little advanced generator code...), as well as %SQLImportMgr's  GenerateImportRoutine() method.

2. I don't know if this is relevant for your case, but also for the benefit of the wider community and other use-cases, when it comes to bulk/batch fast operations, if Java or .Net are relevant, then our XEP (eXtreme Event Processing) framework could be a good option. And there indeed you have control over when to perform the indexing.

3. I know the discussion was geared towards OOP and not SQL (and the SQL %NOINDEX option was mentioned more than once), depending on how the data is arriving, you might want to consider using the latest (SQL-based) LOAD (BULK) DATA capability.

4. Relating back to #2 above, re XEP. Behind the scenes the XEP access uses (in some cases) a server-side %SaveDirect() method. In theory you can use this yourself. Note it does not address the no indexing topic (again you can consider using #1 - %SortBegin() and %SortEnd() for that) but it has some other performance advantages as apposed to a regular %Save() (it also has some limitations...). Note there is quite an amount of "hassle" about "preparing" the data for this method, as it needs to be in the $ListBuild format the class's storage expects (and possibly other data nodes). Therefore it is quite rarely used directly (not via XEP). But if you have high performance needs, it might be worth considering this, and comparing the benefit it could provide you vs. the drawbacks it has.

Hi Ephraim,

There could be several reasons - 2 common ones are database expansion and journal expansion (or both).

Here are some sample good resources to see more about this topic -

Hope this helps.