Issues with Multicardinal Field Splitter Processor Handling XML

[SethLewis1]

I'm having difficulty using the Multicardinal Field Splitter Processor to write to REST a 1:M XML structure. My service handles a file inbound transport whose structure is shown in the pseudo XML below.

<Incident>
    <Other>
       <Incident_Number></Incident_Number>
    </Other>
       <Units>
    <Unit>
        <Unit_Id>Value 1</Unit_Id>
        <Notified_Dttm></Notified_Dttm>
        <Enroute_Dttm></Enroute_Dttm>
        <Cancelled></Cancelled>
        <Cancelled_Dttm/>
        <Arrival_Dttm></Arrival_Dttm>
        <Patient_Arrival_Dttm/>
        <Enroute_Destination_Dttm/>
        <Arrive_Destination_Dttm/>
        <Cleared_Dttm/>
        <Transfer_Of_Care_Dttm/>
        <In_Service_Dttm/>
        <Home_Dttm/>
        <Hours></Hours>
        <Mileage></Mileage>
        <Lights_Sirens_To_Scene/>
        <Unit_Role/>
        <Notes/>
        </Unit>
       <Unit>
        <Unit_Id>Value 2</Unit_Id>
        <Notified_Dttm></Notified_Dttm>
        <Enroute_Dttm></Enroute_Dttm>
        <Cancelled></Cancelled>
        <Cancelled_Dttm/>
        <Arrival_Dttm></Arrival_Dttm>
        <Patient_Arrival_Dttm/>
        <Enroute_Destination_Dttm/>
        <Arrive_Destination_Dttm/>
        <Cleared_Dttm/>
        <Transfer_Of_Care_Dttm/>
        <In_Service_Dttm/>
        <Home_Dttm/>
        <Hours></Hours>
        <Mileage></Mileage>
        <Lights_Sirens_To_Scene/>
        <Unit_Role/>
        <Notes/>
        </Unit>
    <Unit>
        <Unit_Id>Value 3</Unit_Id>
        <Notified_Dttm></Notified_Dttm>
        <Enroute_Dttm></Enroute_Dttm>
        <Cancelled></Cancelled>
        <Cancelled_Dttm/>
        <Arrival_Dttm></Arrival_Dttm>
        <Patient_Arrival_Dttm/>
        <Enroute_Destination_Dttm/>
        <Arrive_Destination_Dttm/>
        <Cleared_Dttm/>
        <Transfer_Of_Care_Dttm/>
        <In_Service_Dttm/>
        <Home_Dttm/>
        <Hours></Hours>
        <Mileage></Mileage>
        <Lights_Sirens_To_Scene/>
        <Unit_Role/>
        <Notes/>
        </Unit>
    </Units>
</Incident>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Here's the simple service I'm going for (below). When the XML is processed by the input, I'd like for 1 process to map its geometry and incident_number fields to a simple flattened table in a RDBMS. I'd like the multicardinal field splitter to parse out the 1:M records to a flat table in the same RDBMS that's linked via a relationship class. I need to preserve the incident_number element from the <Other> grouping to make the 1:M relationship with the geometry table work.

With the latest release of this processor, only the first childIndex value is returned. I've seen this behavior in both the Feature Service Output shown above as well as with a simple File JSON output on the same server. What am I missing in how to address this (admittedly simple) workflow? Lastly here's the definition that GeoEvent creates upon ingesting the XML.

Could the issue be due to Unit being seen as a Group as well, event after the Multicardinal Splitter drops Units?

RJ Sunderman‌ I'm wondering if anything stands out about how I'm approaching this.

[RJSunderman]

‌

Hello Seth Lewis –

I suspect that you're running into trouble with GeoEvent Server's internal translation from XML to JSON. I worked some with a sample XML structure similar to what you show above, but I'm unable (yet) to figure out how to configure my input such that Units is an array (cardinality 'Many') of individual Unit elements (cardinality 'One').

I'll be back in touch if I can figure out a work around or get this to work –
RJ

[RJSunderman · Accepted solution]

Seth –

I think I've confirmed that third party libraries we incorporated into GeoEvent Server to handle XML to JSON translation changed how "root" elements and arrays are recognized and handled. I've created some XML which I think follows the sample you provided above and successfully configure a GeoEvent Server inbound connector and GeoEvent Definition capable of ingesting the XML data.

Your original XML data structure collects several Unit elements and organizes them beneath an element named Units. There's nothing wrong with this; I can mock up JSON which represents Units as an array of Unit objects which passes on-line validation. I do not agree 100% with how the third party (internal) libraries we're using translate the XML to JSON – they seem to want both Units and Unit to be handled as arrays of values (multicardinal).

I've attached a write-up which shows the XML I used to test and discusses my approach for accomplishing what I think you are trying to do. I ended up allowing GeoEvent Server to create a GeoEvent Definition for me, altering that GeoEvent Definition to accommodate multicardinal data structures, editing the input to use my tailored GeoEvent Definition, then using a pair of Multicardinal Field Splitters to split out each responding vehicle's data joining it to the common data for an incident. From there I can use normal Field Mappers to copy data from the processed event record schema(s) to match the schema expected by a pair of feature services so that each XML incident record received ends up adding/updating an incident's common data along with potentially several vehicle feature records ... which you can relate within the back end geodatabase using a 1:M relationship.

I hope the attached is helpful –
RJ

Note:  I indicate in the attached PDF that "the current implementation of the Multicardinal Field Splitter processor does not allow two or more instances of the processor to be placed in series." Please make sure you have the latest version of this processor downloaded from the processor's page in the GeoEvent Server Gallery. I was using an older release of the processor. Eric Ironside‌ has updated the processor so that its addition of a childIndex no longer interferes with placing two or more Multicardinal Field Splitter processors in series.  (RJ)

[SethLewis1]

Thank you RJ for your thorough answer and help on this issue.