The documentation for %Net.HttpRequest has some sample code that should be useful:

From that page:

In order to send parameters on the URL, i.e. when you see a URL like

http://www.demo.com/page.html?PARAM1=TEST&PARAM2=HELLO

You use the SetParam method to add these parameters one by one. For example to get the index page from 
Documatic you do:

    Set httprequest=##class(%Net.HttpRequest).%New()
    Set httprequest.Port=1972
    Do httprequest.SetParam("PAGE","INDEX")
    Do httprequest.Get("/csp/docbook/%CSP.Documatic.cls")
    Do httprequest.HttpResponse.OutputToDevice()

You may also pass the query parameters on the Get call directly too as long as they are correctly escaped.

In addition to setting FetchSize, we can also improve the speed with an optimization to how EnsLib.SQL.GatewayResultSet fetches rows for large result sets.

This optimization is planned to be included in a future product version, but it is possible to do this in current versions with custom code. What version of Ensemble are you using?

Guillaume, do you know who the InterSystems Sales Engineer is for your company? We should discuss this by email and we can get you some sample code.

File operations pull the value for %f from the "Source" property of the EnsLib.EDI.XML.Document object. In your code sample you're creating a new EnsLib.EDI.XML.Document and copying the output from your XSLT transformation into it, but you're not setting Source to anything. As an experiment, try setting Source to a value and confirm that your output file is given that name.

set xmlResultDoc.Source="MyFileName.xml"


If you want %f to use the same filename as the original input file then you'll want to grab the Source value from your original object that was created by the business service and copy it to xmlResultDoc.Source.

Looking at the generated code, this is probably not possible.

Each context variable becomes a standard property in an auto-generated context class. The "Default Value" becomes the "InitialExpression" attribute of the property. This means the default is assigned by the underlying object framework upon instantiation of the context object rather than by the BPL engine itself.

Class Test2.NewProcess1.Context Extends Ens.BP.Context [ ClassType = persistent, CompileAfter = Test2.NewProcess1, GeneratedBy = Ens.BPL.Compiler.CLS, ProcedureBlock ]
{

Property testvar1 As %String(MAXLEN = 50) [ InitialExpression = "blah" ];

}

Have a look at the separators and framing settings in EnsLib.HL7.Operation.FileOperation. The sixth item in Separators is the segment terminator (carriage return in standard HL7) while Framing lets you change the message terminator (line feed in standard HL7). You can change these to non-standard values if needed.

From the separators documentation linked above:

Separators
 HL7 separator characters to use in the outgoing message. If you leave this field blank, the default is:
 
|^~\&
 Basics
 An HL7 message uses special characters to organize its raw contents. These characters may vary from one clinical application to another. For this reason, the HL7 standard requires that each HL7 message list the five specific characters that it is using as separators at the start of the MSH segment, in order from left to right:
  1.  Field separator (FS)
  2.  Component separator (CS)
  3.  Repetition separator (RS)
  4.  Escape character (ESC)
  5.  Subcomponent separator (SS)
A sixth character, the segment terminator character, is not specified in MSH and is generally assumed to be a carriage return (ASCII 13).
Details
 For Separators, you must supply a string of characters which Ensemble assigns to HL7 separators in left to right order: FS, CS, RS, ESC, SS as described in the previous list.
 Beyond positions 1 through 5 of the Separators string, you can supply additional characters to override the default segment terminator character, the carriage return (ASCII 13). After position 5, use \r for the carriage return (ASCII 13) and \n for the line feed (ASCII 10).
 You can use \x in positions 1 through 5 if you need to specify segment terminators in positions 6 and higher but want your output messages to use fewer than 5 separators. Separators designated by \x in positions 1 through 5 are not used. The purpose of \x is simply to extend the length of the list of separators so that position 6 is interpreted correctly as the first segment terminator.

I see an issue in the first piece of code you posted.

At the top of the method you do this:
set pInput=pRequest.FileStream

But when you write the stream to the file, you do this:
set status=..Adapter.PutStream(..Filename, pInput.Stream)
 
I don't know for certain what type of object pRequest is or pRequest.FileStream, but in the service you posted it looks like pRequest.FileStream is a %Stream.Object.

Method OnProcessInput(pInput As %Stream.Object, Output pOutput As %RegisteredObject) As %Status
...
set pt.filestream=pInput

If pRequest.FileStream is a %Stream.Object, then it won't have a Stream property and passing pInput.Stream to PutStream should fail. Try changing this to:
set status=..Adapter.PutStream(..Filename, pInput)

The method signature for OnMessage usually only has two parameters: the inbound request and a response to return.

In your method you have three parameters and two of them seem to be inbound requests. Can you clarify?

Method OnMessage(pREs As TestingEnvironment.ECGTrace.TEST.FSMREQ, pRequest As Ens.StreamContainer, Output pResponse As %Persistent) As %Status

IIRC "#" means that the character doesn't exist in the chosen font. The default font may not be very complete. You might want to explicitly set the font you're using to one you know contains Cyrillic characters.

Also, in your Zen Report class you can set the encoding as a parameter. This may not be necessary since it should default to UTF-8:
Parameter ENCODING="ISO-8859-1";

I'd suggest contacting the WRC to help look at the problem you're seeing with unwanted characters in the output. EnsLib.RecordMap.Operation.BatchFileOperation does what you've described, so it would be best to get this working for your use case if possible.

Looking at the code you posted...

pRequest.Records.GetAt(1)

This will just get you the first record from the batch. If you want to get a specific field from a record you would want to use something like:

pRequest.Records.GetAt(1).FieldName

One thing I see is that you don't need a value for the "key" attribute in the assign for callrequest.EOBList.  Key is used to assign the value to a specific member of an array/list whereas it looks like you want to assign the entire list.

Does this work better?
<
assign property="callrequest.EOBListvalue="context.tEOBListaction="set" key="/>

Are StageBatchId and Filename getting passed correctly?

Archunan,

Can you give some more details about your use case? I'm having trouble picturing what the downstream system should receive.

Should the receiving system just receive a single message that combines the HL7 and flat records together like this?

MSH|^~\&||HC6|||||MDM^T02|||2.5
EVN|T02|20180117094500
PID|||LD572046^^^HC6^MR||Smith^John||19301019|M|||1 Memorial Drive^^Cambridge^MA^02142||||||||063070516
PV1||O|||||ISCGP001^Moore^James|||||||EO|||||HSVN00006|||||||||||||||||||||||||20180117094500|20180117094500
TXA||Progress note||201801170945|JJ021^James^John||||ISCGP001^Moore^James|||19815952^TRANS
OBX||FT|RTF^TRANS||Patient complaining of pain in right big toe. Toe red in colour. To commence on antibiotics.||||||R
FlatFileRow1Field1,FlatFileRow1Field2,FlatFileRow1Field3
FlatFileRow2Field1,FlatFileRow2Field2,FlatFileRow2Field3
FlatFileRow3Field1,FlatFileRow3Field2,FlatFileRow3Field3