This line causes an error:

Write tMessage.Name,!

Your class does not have Name property, so it causes an error.

The following method works :

/// Do ##class(Testing.Messages.Session).test()
ClassMethod test()
{
    Set messagedata = "<?xml version=""1.0"" encoding=""UTF-8""?><session><sessionId>124364</sessionId><cabinet>demo</cabinet><eventType>IN</eventType><eventTime>20161006160154</eventTime><login>test</login><loginFirstName>test</loginFirstName><loginLastName>test</loginLastName></session>"
    Set reader = ##class(%XML.Reader).%New()
    Set status = reader.OpenString(messagedata)
    Do reader.Rewind()

    If $$$ISERR(status) {do $System.Status.DisplayError(status)}

    // Associate a class name with the XML element name
    Do reader.CorrelateRoot("Testing.Messages.Session")

    // Read objects from xml data
    While (reader.Next(.tMessage,.status)) {
        Do:$$$ISERR(status) $System.Status.DisplayError(status)
        Write tMessage.sessionId,!
    }
}

Terminal:

USER >do ##class(Testing.Messages.Session).test()
124364

Disclaimer. I am not familiar with EDI.

Some solutions would be:

  • Get official EDI 271 xsd schema files and import them into Caché
  • Alternatively you can read EDI 271 specification/check examples and write your own classes

Then you need a dtl to transform incoming message into your new classes. If there's a lot of them maybe it would be better to write one generic transformer or write a transformer generator based on class (which would generate transformation method based on class properties).

After that you  can transform your class object into json via several ways:

  • Old json via %ZEN.proxyObject/%ZEN.auxillary.jsonProvider
  • New json via dynamic objects

The largest pool size is recommended to be the same as the number of CPUs in the Ensemble server, since there are only going to be as many jobs available as the number of CPUs.

Why should number of jobs be less or equal to the number of cores? I tested (admittedly only one) BP for processing some objects and results (messages processed per second) were better with PoolSize=100, than with PoolSize=50 on a system with 1CPU/8cores.