Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Methods, data structures and architectural concepts of Management and re-delivering Business Objects in Resource Adapters

IP.com Disclosure Number: IPCOM000199980D
Publication Date: 2010-Sep-23
Document File: 8 page(s) / 157K

Publishing Venue

The IP.com Prior Art Database

Abstract

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. note # : why we preferred Message digest is because we could maintain the Unique reference mapping, MD collides only if the Bos are same which could never happen, even if there appears a case in future, since they are same it could map to same business Object which in turns adds exception for processing the Bo once more and instead the same Mapped Objects could be used.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

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

beginning.

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-

re-delivered.

Pseudo Failure / Wrong failure:

1

Page 02 of 8

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.

Performance problem:

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...