GeoEvent Processor: Invalid JSON Output on WebSocket
The JSON Output via WebSocket on the ArcGIS GeoEvent Extension returns invalid JSON Objects if the GeoEvent Service has to handle more than one track at the same time.
In our test scenario we have a simple GeoEvent Service that receives JSON on a REST endpoint. The output JSON will be provided via WebSocket.
To simulate the tracks that will be send to the REST endpoint we used a small JavaScript Tool that is attached.
In general the data that is received via WebSocket contains valid JSON objects, but when sending more than one track to the REST endpoint, we very often receive invalid JSON objects within the data objects of the WebSocket message.
Following is unexpected in the data string of the message:
- data contains a complete JSON Track followed by one more curly bracket ‘{‘
- the starting curly bracket ‘{‘ of the JSON Track is missing
- data contains two complete JSON Tracks without any separator or squared brackets to define it as list {“geometry”: …. , “TrackID”: 1}{“geometry”: …. , “TrackID”: 2}
It’s possible to see the problem when connection the WebSocket endpoint with the integrated website:
Is this a already known Issue? Is there any chance to configure the GeoEvent Processor to send exactly one track per message?
The most important thing is that we expect to get a valid JSON object within every WebSocket message.
Hello Rainer -
Yes, please confirm the release of GeoEvent that you are using. I seem to recall occasionally seeing the generic JSON adapter output invalid JSON records when sending many dozens of events a second to an outbound connector. The issue had nothing to do with the TRACK_ID or unique identification of tracks however, so I'm not sure if the issue I'm recalling has anything to do with what you are observing. The issue I'm recalling was addressed in the 10.2.2 product release I believe.
In any case, I used your JavaScript Track Simulator to simulate a half-dozen inbound tracks. Your tool is generating Esri Feature JSON (which GeoEvent interprets / adapts using its "JSON" adapter) as opposed to Generic JSON or the GeoJSON format (supported at the 10.3.1 product release).
I fed your simulator's input into a 'Receive Features on a REST Endpoint' input and directed GeoEvents adapted by that input to a 'Push JSON to an External WebSocket' output.
I created a 'Receive JSON on a WebSocket' input (which runs in SERVER mode) to provide a hosted WebSocket for the output (which runs in CLIENT mode) to connect to. Finally, I created a 'Write to a JSON File', configured to not output formatted JSON, and configured a GeoEvent Service as follows:
I typically refer to this as a "WebSocket Chain". The input to the upper-left, accepting Esri Feature JSON from your simulator, could be receiving any data feed. It sends the GeoEvents it constructs to a WebSocket output which are subsequently received by the paired WebSocket input (the second input illustrated above). GeoEvents received by this second input are then redirected into the system file.
I ran the simulation for five minutes receiving a total of 1788 events on the rest-features-in input. All of the events received by this input were processed through the WebSocket Chain and were written into the *.json system file. Copying the contents of the *.json system file into an on-line JSON validator I found the file's contents to be valid and the expected number of events in the file. If the generic JSON adapter, the component responsible for generating the payload sent out the websocket-external-json-out, were generating invalid JSON I would expect to see some level of event loss in the *.json system file.
I ran my tests using the 10.3.1 release candidate of GeoEvent.
- RJ
