Thanks for pointing this our and glad to see you're actively working with IRIS. As Vic has  pointed out although the ObjectScript VSCode extension has been announced, we haven't yet released our first release 1.0. See the  https://community.intersystems.com/post/intersystems-joins-open-source-objectscript-vs-code-effort message from @Raj Singh .

In fact, the BPL editor (IDE) is only available in Studio and the Management Portal. We'll fix this.

 Although you certainly can use the existing extension, it is not an InterSystems offering. We are in the process of revising recommendations to use Atelier. Once the VSCode extension is released we will have documentation for it.

For now, if you're working with productions, I'd recommend using InterSystems Studio or the Management Portal. Atelier can also be used but doesn't have any advantage over Studio.

Thanks for finding this. We'll fix it. We have two sets of Python doc: the automatically generated reference (from source code comments) https://docs.intersystems.com/irislatest/csp/docbook/Python-Native/irisnative.iris.html#irisnative.iris ,  which you were using and the User's Guide and Reference https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=BPYNAT_refapi#BPYNAT_refapi_iris_get-client-version , which has the correct information.

Obviously we generated the reference with an earlier version of the software and didn't update it after the change. We will fix that.

I would recommend using the User's Guide and Reference https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=BPYNAT rather than the automatically generated one.

If you find any problems in the User's Guide and Reference, you can click on the Help us improve this page tab on the right and we'll fix it. We haven't yet added it to the automatically-generated reference. You can also send us a comment  at documentation@intersystems.com.

The WRC is InterSystems Worldwide Resource Center, our support group. No need to contact them over this, but they are a great resource for many issues.

Thanks for the comment. Is this description clearer?

Using the /api/mgmnt Service to Create a REST Service

The recommended way to create a REST service is to create an OpenAPI 2.0 (also called Swagger) description for the REST service and use that to generate the REST service classes. If you are implementing a REST service defined by a third party, they may provide this OpenAPI 2.0 description. See the OpenAPI 2.0 Specification for details about the format of an OpenAPI 2.0 description. The following topics describe how to use the /api/mgmnt service to do this.

Using the /api/mgmnt Service to Generate the Classes

In the first step, generate the REST service classes, as follows:

  1. Create or obtain the OpenAPI 2.0 description of the REST service, in JSON format.

Thanks again and feel free to use the "Help us improve this page" link on any of our documentation pages to send us a comment.

If you do need to do this in a router. Here is the overall process.

  1.  Define a business rule. Make it a General Message Routing Rule and have the assist class be EnsLib.MsgRouter.RuleAssist.
  2. Add a rule to the rule set and double-click Constraint. Specify the rule class
    Persistent > ENS > StreamContainer
    That's the message class used by the pass-through file service/operation. You can also specify the business service as the source.
  3. Double-click  condition, and in the expression editor specify Document.Type or Document.OriginalFilename, add an operation, and a  value.
  4. Send it to the correct operation.
  5. Define a router business process and specify the rule you just created.
  6. Connect the pass-through file service to the router.

But you may not need the router at all.

I'm not sure that the Ensemble Record Mapper makes this much easier than just reading the stream. Unless you don't treat the end of line as terminator, each line will be a separate record. It is possible that you could use the Complex Record Mapper to create one record from the file using the first column as the leading text, but that requires defining one record map for each line in the file. I'm not sure how to handle the Hospital name and blank lines. I don't think that batch record map would help because there's different kinds of information on each line.

But I think most of the work is not going to be parsing the input file but in making sure that the HL7 message has all the right segments and fields.

Part of the reason is that this is a HealthShare feature, not an Ensemble feature. So that probably caused at least one of the switches. [Do confirm that the sales contact understands this.]

good luck

The big efficiency improvement is in 2016.1. Before that you'll only get a minor improvement going to record map  batch. This is an incentive to upgrade to a new version.