I have a question regarding the Field Calculator processor. I have a Date field in my stream and i need to parse it in order to keep the Month in a separate field. Is it something that can be configured while setting the Field Calculator?
Can you provide me a sample of how the date/time values are being sent to GeoEvent Processor? Are you interested in receiving a string value such as "14-7-2012 02:30:45 PM" and allowing an input connector to use an Expected Date Format mask such as dd-M-yyyy hh:mm:ss a to interpret the string as a Date ... July 7, 2012 14:30:45 in this case ... and then then pull the Month portion out as a numeric (e.g. 7 for July)?
We might be able to use substring( ) or a Regular Expression to pull a portion from a date/time String which represents the month, if the date/time is brought in as a String. But if you need the Input to convert the value it receives to a Date, we may have trouble trying to get the month out of the Date object.
You will want to configure a Field Calculator whose Expression looks something like substring(DateAsString,5,7) to pull a two character substring out of a date/time field received as a String and write the retrieved sub-string to a new field. The index values 5 and 7 in the substring( ) syntax specify the starting index and ending index of a zero-based array of characters.
The downside of this is that the date/time value must be specified, by the GeoEvent Definition, as a String and the service elements in the GeoEvent Service will only be able to work with the date/time as a String ... not a Date. You can work around this by feeding the event data back into a second input and allowing the second input to handle the conversion of the String representation of the date/time to an actual Date value.
Details are included in the attached PDF.
Please note that support for Java String functions from within a Field Calculator is supported in the 10.2.2 release of GeoEvent Processor, which should be publically available on your Customer Care Portal tomorrow 15-April-2014. Esri Distributors should have been given access to download the new release last week.