GeoEvent: disable rollback on output feature service connector

3495
2
Jump to solution
06-24-2015 01:13 AM
ThibautDelaere1
Occasional Contributor

Hello,

Is there a possibility to disable the rollback on faillure on an output feature service connector?

At the moment it is 'true' by default. So when trying to add/update 100 features and 1 is giving an error 100 features (or feature updates) are lost (rolled back) instead of the only the one giving an error.

Regards,
Thibaut

0 Kudos
1 Solution

Accepted Solutions
RJSunderman
Esri Regular Contributor

Hello Thibaut -

Unfortunately it is not possible to configure the rollback on failure behavior for either the 'Add a Feature' or 'Update a Feature' output connectors. This behavior is part of the underlying transport's implementation and it not exposed to the user.

The situation you describe, in which a transaction containing 100 feature records includes one record which violates a constraint imposed by the feature service (for example, a string whose length exceeds the what is allowed for a particular field, or a <null> value pushed into a field whose specification indicates nullable: false) will cause the entire transaction to rollback ... and none of the event data in that transaction will be applied to add or update features.

You have two options:

1) Use GeoEvent filters to screen for event attributes which do not satisfy your feature service's constraints. Then use a Field Calculator to write compliant data into the event -- or allow the Filter to discard the event so that it is not included in an add/update features transaction.

2) Adjust the 'Maximum Features Per Transaction' property on your  'Add a Feature' or 'Update a Feature' output connectors from the default 500 to a lower number. That way, when a transaction is rolled back, you do not lose as much event data.

If you know that event data from a data provider often contains values your feature service will consider invalid, you can set the 'Maximum Features Per Transaction' property to 1. Understand that limiting GeoEvent to exactly one event per transaction with the database will increase transaction overhead and limit the number of events you can add/update each second.

Hope this information helps -

RJ

View solution in original post

2 Replies
RJSunderman
Esri Regular Contributor

Hello Thibaut -

Unfortunately it is not possible to configure the rollback on failure behavior for either the 'Add a Feature' or 'Update a Feature' output connectors. This behavior is part of the underlying transport's implementation and it not exposed to the user.

The situation you describe, in which a transaction containing 100 feature records includes one record which violates a constraint imposed by the feature service (for example, a string whose length exceeds the what is allowed for a particular field, or a <null> value pushed into a field whose specification indicates nullable: false) will cause the entire transaction to rollback ... and none of the event data in that transaction will be applied to add or update features.

You have two options:

1) Use GeoEvent filters to screen for event attributes which do not satisfy your feature service's constraints. Then use a Field Calculator to write compliant data into the event -- or allow the Filter to discard the event so that it is not included in an add/update features transaction.

2) Adjust the 'Maximum Features Per Transaction' property on your  'Add a Feature' or 'Update a Feature' output connectors from the default 500 to a lower number. That way, when a transaction is rolled back, you do not lose as much event data.

If you know that event data from a data provider often contains values your feature service will consider invalid, you can set the 'Maximum Features Per Transaction' property to 1. Understand that limiting GeoEvent to exactly one event per transaction with the database will increase transaction overhead and limit the number of events you can add/update each second.

Hope this information helps -

RJ

ThibautDelaere1
Occasional Contributor

Thanks for the information!

It might be a good idea to expose the rollback option to the user in a next version.

Regards,

Thibaut