Methods, data structures and architectural concepts of Management and re-delivering Business Objects in Resource Adapters
Publication Date: 2010-Sep-23
The IP.com Prior Art Database
Abstract The invention covers the methods, computer program, products and systems for any JCA adapters in combination of any Runtime. The invention reveals the technical user from analyzing the Failure types and its categorization, handling them according to the category from the adapter side which can be done by extending the feature of Adapter without complimenting JCA specification. The invention is implemented, by managing a new status of the event in the Event Table which categorizes the failure. (0,1 and -1 are the 3 Status currently supported be the adapter representing wait , Success and fail) The new Status is any number n, to categorize the Failure Type. we could also use the message Digest(MD5 preferably because it is a 32charactered hexadecimal) , so that the Mapping between the event and its corresponding Bo Process status could be maintained without any other references.
Page 01 of 8
Methods, data structures and architectural concepts of Management and re -delivering Business Objects in Resource Adapters
Failure conditions of Resource Adapters:
In Adapters we maintain a mechanism of delivering the event to the endpoint after Business Object is processed.
During an Inbound operation, exceptions can occur either at the event processing stage or during the delivery of the event to the endpoint.
When the exception occurs at the event processing, the adapter during recovery will perform the corrective action based on the status of the message in the event store table.
If the endpoint is down adapter fails to deliver the Processed Business objects to the endpoint and in turn set the process information to fail. Through which the Adapter categorizes this Bo as Failed BO, even though it is actually not a failed Business Object and the failure had occurred in delivering.
Currently when the User sees the Adapter processing failed. The technical user uses a backup mechanism where he checks for the failed events and corrects it to be re-
processed from the
processed but instead
When working with Resource Server, the Failed Event Manager will be used to resubmit the failed events after performing corrective actions, if needed
In the current situation, whenever a failure occurs in the delivery of the Business Event to the endpoint, the Adapter performs a retry for the specified number of times within a configured duration and then categorizes the Event to be a failure. The failure in this case is due to the unavailability of the endpoint to receive the message.
There reflection of the Problem is associated with i.e The Above mechanism has Problems associated which are given below
1) Business Objects reprocessing
2) Pseudo Failure / Wrong failure
3) User interaction
4) Performance problem
Business Objects reprocessing:
Despite there was no Failure in the Business Object processing and the failure was in delivering the event, The Business Object processing is done again when the user retries by submitting the event again. The method we are proposing now will handle this case where the Bo is already processed to be in a Different status which should not be re-
Pseudo Failure / Wrong failure:
The event delivery failure is considered by us as a false/Pseudo failure. According to us (the article) we are not categorizing the failure of delivery as a Fail status, instead we make a different type of categorization to handle such pseudo failures.
User interaction: The user may not filter the type of failure and think of the situation of failure looking in the trace. for the above mentioned pseudo-failure cases. User required to Re-run the Events independent of whether it is an actual Bo Error or Delivery Error.
The user attempting to reprocess, by adding filters and the Adapter reprocessing is an extensive Performance issue.
The aim of the article is about categorizing the fa...