It is possible for an error to occur after a collaboration has sent a business object request to any destination connector to which it is bound and before receiving a response from the connector as to whether or not the connector successfully processed the request in its respective application. If the connector is unable to process the request, then it needs to process it again when the error is resolved. If the connector is able to successfully process the request, though, and is in the process of sending InterChange Server Express a notification of that successful processing when the error occurs, then InterChange Server Express does not receive the notification. The last record of the state of the request would indicate that the request still needs to be processed. As a result of this inaccurate state record the request would be processed a second time, resulting in duplicate data.
To guard against this complication when configuring non-transactional collaborations, you can enable the Persist service call in transit state checkbox. This causes InterChange Server Express to persist any business object requests that are in transit to destination applications when an error occurs. The requests are not sent when the system recovers, reducing the risk of the request being processed twice in the destination applications. You can then use Flow Manager to examine the requests and can investigate the destination applications to determine whether or not the requests were processed successfully before the error occurred. You should discard any requests that were processed successfully and resubmit any that were not processed successfully. See also
[ Top of Page | Previous Page | Next Page | Table of Contents ]