Follow-up: Disable rollback on output feature service connector
Accepted Solutions
Hello Nicholas –
A few things have changed since I replied to Thibaut back in August 2015. From the GeoEvent Server side, it is important to know that a Field Calculator processor's expressions support a number of different string functions. From the ArcGIS Server side, the ArcGIS REST Services API changed at the 10.7 release to offer clients an ability to specify whether or not to rollback a transaction if a failure is encountered.
GeoEvent Server has not yet integrated the changes made to the map/feature services REST API. That means that at the latest releases (10.6.x and 10.7.x) you will not be able to configure an output in GeoEvent Manager to specify that a transaction should or should not rollback when restrictions enforced by the feature service (such as string length) are not satisfied.
I also want to clarify what I meant when I said "use GeoEvent filters to screen for event attributes which do not satisfy your feature service's constraints". On the one hand, you could use a filter to discard event records whose eventId attribute were null. This would allow you to catch and discard event records whose undefined event identifier would otherwise fail to satisfy a nullable: false restriction enforced by a feature service.
You cannot configure a filter with an expression such as length(eventId) however, so its not possible to configure a filter to discard event records whose event identifier string is "too long" to be used when adding or updating a feature record. What you can do is configure a Field Calculator to trim the string value to a compliant length or remove portions of a string you know make the string too long.
The simpler approach is discussed in the Introduction to GeoEvent Server tutorial, Module 4 pages 10-12. The Field Calculator (Regular Expression) processor can be configured with a regular expression which applies a quantifier (or match count) to a portion of a pattern. The example illustrated below anchors the pattern match to the beginning of the string in the Description attribute and matches zero-up-to-thirty-two single characters. The matching sub-string is then written back into Description effectively trimming the string's length.
Your other option is to use a regular Field Calculator which supports a variety of string functions discussed on that processor's page in the on-line help. For example, say that you wanted to eliminate all of the text between two delimiting dashes to simplify a description.
Given the string: Flight SWA2607 - Departed 17:20 hours - OnTime
You could use an expression: replaceAll(eventid, '^(.*)([ ][-][ ].*[ ][-][ ])(.*)', '$1 - $3')
to effectively cut out the departure time and rewrite just the first and third parts of the string.
The regular expression pattern in that second example uses rounded parentheses to identify three groups with two sets of three square parentheses to identify single characters ... a space followed by a dash followed by another space. Each .* in the pattern matches zero or more characters, so we effectively parse out the flight number and its status (e.g. "OnTime") and throw away all the stuff in the middle of the string.
Hope this information helps –
RJ
Hello Nicholas –
A few things have changed since I replied to Thibaut back in August 2015. From the GeoEvent Server side, it is important to know that a Field Calculator processor's expressions support a number of different string functions. From the ArcGIS Server side, the ArcGIS REST Services API changed at the 10.7 release to offer clients an ability to specify whether or not to rollback a transaction if a failure is encountered.
GeoEvent Server has not yet integrated the changes made to the map/feature services REST API. That means that at the latest releases (10.6.x and 10.7.x) you will not be able to configure an output in GeoEvent Manager to specify that a transaction should or should not rollback when restrictions enforced by the feature service (such as string length) are not satisfied.
I also want to clarify what I meant when I said "use GeoEvent filters to screen for event attributes which do not satisfy your feature service's constraints". On the one hand, you could use a filter to discard event records whose eventId attribute were null. This would allow you to catch and discard event records whose undefined event identifier would otherwise fail to satisfy a nullable: false restriction enforced by a feature service.
You cannot configure a filter with an expression such as length(eventId) however, so its not possible to configure a filter to discard event records whose event identifier string is "too long" to be used when adding or updating a feature record. What you can do is configure a Field Calculator to trim the string value to a compliant length or remove portions of a string you know make the string too long.
The simpler approach is discussed in the Introduction to GeoEvent Server tutorial, Module 4 pages 10-12. The Field Calculator (Regular Expression) processor can be configured with a regular expression which applies a quantifier (or match count) to a portion of a pattern. The example illustrated below anchors the pattern match to the beginning of the string in the Description attribute and matches zero-up-to-thirty-two single characters. The matching sub-string is then written back into Description effectively trimming the string's length.
Your other option is to use a regular Field Calculator which supports a variety of string functions discussed on that processor's page in the on-line help. For example, say that you wanted to eliminate all of the text between two delimiting dashes to simplify a description.
Given the string: Flight SWA2607 - Departed 17:20 hours - OnTime
You could use an expression: replaceAll(eventid, '^(.*)([ ][-][ ].*[ ][-][ ])(.*)', '$1 - $3')
to effectively cut out the departure time and rewrite just the first and third parts of the string.
The regular expression pattern in that second example uses rounded parentheses to identify three groups with two sets of three square parentheses to identify single characters ... a space followed by a dash followed by another space. Each .* in the pattern matches zero or more characters, so we effectively parse out the flight number and its status (e.g. "OnTime") and throw away all the stuff in the middle of the string.
Hope this information helps –
RJ
