Input Format with : String

Question

I have a device that send the following string to GEP
"POS:TRAFFAVL0049,1363478415,+25.32340050,+51.48632812,-12.847000,548946,2800847,3.9,141.7,35,16,0,1.570,44,39R"

The first String POS is a static value, but next to : is a dynamic value as in the example above it's TRAFFAVL0049. 
As I understand the string sent to GEP should contain in the first string a name of geoevent definition.
How I can create a GeoEvent defenition based on the above String.

RJSunderman · Answer

In this case I would recommend that you alter your Input component's configuration to indicate that, no, the event stream does not contain the name of the event definition. You will want to specify that, yes, you do want a fixed event definition to be created and provide a name which does not include the ':' which the product currently recognizes as an illegal character. Please see the attached screenshot below.

The event definition created will be reused for every event whose signature (number of attribute fields and data types) matches the first event received.

- RJ

CreatedFixedEventDefinition.jpg

aymansalah · Answer

Hello RJ Sunderman,
Thank you this was very helpful, just want to say that My String dosn't have quoted it was my mistake. 
The only problem I face is the first part of the String which is POS:, Geo Event will not accept a GeoEvent Definition with name containing :, in this case do I have to develop a customized Adapter?

RJSunderman · Answer

Hello Ayman -I have a device that send the following string to GEP
"POS:TRAFFAVL0049,1363478415,+25.32340050,+51.48632812,-12.847000,548946,2800847,3.9,141.7,35,16,0,1.570,44,39R"

The first String POS is a static value, but next to : is a dynamic value as in the example above it's TRAFFAVL0049.

A quick remark on your input - since the entire string is quoted, your event really only has one input field, a literal string. The fact that the string contains commas is irrelevant. If you want to send events into GeoEvent Processor whose attribute values are comma separated values, you need to drop the quotes so that the attributes will be recognized as separate values. 
As I understand the string sent to GEP should contain in the first string a name of geoevent definition.
How I can create a GeoEvent defenition based on the above String.

Receiving event data as comma separated text, you can configure an Input connector (�??Receive text from a TCP Socket�?? for example) to use the first field's value to determine an appropriate event definition to apply to the remainder of the event�??s payload (e.g. the remaining comma separated values). But you don�??t have to�?�

Figure 1 below illustrates the default �?? the Input is configured to expect the event definition be specified as the first value. If you can change the response to the first Yes/No parameter to �??No�?? a new parameter will appear asking if you want GEP to attempt to create event definitions for events it does not recognize based on data discovered in the event (see Figure 2).

If you configure your Input to create a fixed GeoEvent Definition, you should specify a name for the event definition that will be created. This implies that all of events received on the specified port will share a common schema �?? a common practice, but not a requirement imposed by the product.

Figure 3 illustrates a more generic case in which you specify that, no, the event data does not specify an event definition, and no, you do not want GeoEvent Process to attempt to create one. Instead, you specify that all events received on the specified port should be evaluated using the specified event definition �?? �??AVL-Data�?? in the illustration. I this case you would need to either create the event definition within Manager, or repurpose an existing definition created previously.

If you absolutely have to �?? because you cannot otherwise have the system component which provides the event data remove the quotes �?? we can probably design a GeoEvent Service which will trim the quotes from the received data string and write the modified event data out as true comma separated values (rather than as a quoted string). A second Input might then be used to re-ingest the processed data �?� but you will find this approach presents you with new challenges such as how you want to handle the processing of duplicate events.

Hope this information helps -
RJ

InputConfigurations.jpg