While trying to do this I've used both my public IP address and my VPN IP address and I get the error 

Couldn't reach InterSystems IRIS at xxx.xx.x.xx:52773. One or both of your IP and Port are incorrect.

Strangely I got this to work last week without having the IAM application or user enabled.  That said I was able to access the IAM portal and set some stuff up but I'm not sure it was actually truly working.  

Any troubleshooting advice?

Please correct me if I'm wrong but I found $system.Status.GetErrorText(sc) was the appropriate method to use over DisplayError() as DisplayError simply writes to the console and would not save to the database or a variable.

Thanks!

I think the WYSIWYG kicked out some chars:​​​

If one were to write or save %objlasterror's output to a database, how would one interpret these characters:

0 ß!>

I find pretty consistently I get this as part of the output which I can work around but isn't helpful.

@Colin Brough I have found generally the message header and body data is a bit putzy to access, but not impossible.  

I'm fairly new at all of this but in the spirit of trying to be helpful: I think a business process in-between that holds on to the metadata for the message in a context object and then pass that all to a custom business operation that uses the data to generate the file name.

I am thinking though that if you are using a message router you can't send the context over, but I think if you use a call operation in the BPL you can pass in the context to the custom operation that you are calling.  You could define a rule then that picks the correct operation to route to and use indirection to call that in the BPL while passing the context.  

Someone more experienced will have to fact check me there.

@Tony Alexander, @Jeffrey Drumm 
I came across your replies here and wanted to confirm I am having the same issue, but I am using the DTL editor and not so much code.  My base ADT is version 2.3.1 and I am transforming to 2.4.  In the DTL it seems that's there's no problem bridging the two messages, however, when the message is ultimately routed out of Ensemble, the message body says the DocType is 2.3.1 but the TypeVersion is 2.4, but also the DocTypeCategory is 2.3.1.  I suppose I would expect that after the transformation the message body would reflect the correct metadata but maybe I misundersand what it's supposed to represent in the context of the whole process?

In the DTL, I select "existing" as the Create action thinking that this will overwrite the data on the base object.

Would be interested in your understanding of all of this.

I have always over-used parentheses for this reason. 

It's also very important when using logical operators:

1=0&&1=0 -> 0&&0=0 -> 1=0 -> 0

(1=0)&&(1=0) -> 0&&0 -> 1

@Eduard Lebedyuk if it helps, I just ran into the same issue and solved it as @Ronald Peña did.  I found it odd that the name of the business service can't defer from the class name (and you can't rename them it seems, at least not in the management portal).  Is this a bug?

I did get my code to work as expected but there's still some unknowns.

I used the example as shown above but also added another block of code to capture the properties that changed into a log.  I also did a KILL on the ^test array before the lines of code were generated.

I either the KILL on the array and/or the number of saves and background calls happening in our system had something to do with my initial issues.  My most apparent issue however, was I wasn't using %code.WriteLine to produce the generated code.  

At the end of the day this will probably go into a local array and not a global so all the update operations don't compete.

I did set some debug targets in the INT code and just opened an object, set a property and %Save().  The ^test array did show a true for the property I changed.  So it worked command on the command line, but something is breaking down when using CSP.