Browse Prior Art Database

Method,Apparatus and architectural concept for determining the delta changes in File content Using Flat-File Adapter.

IP.com Disclosure Number: IPCOM000199967D
Publication Date: 2010-Sep-22
Document File: 8 page(s) / 131K

Publishing Venue

The IP.com Prior Art Database

Abstract

BackGround : FlatFile Resource Adapter Inbound Processing :- The standard way for a Flat File resource adapter to deal with event files having multiple business objects (BOs) is to store the individual BOs as events in the event table with a unique event id. This event id is of the following format: __M_of_N, where N is the total number of BOs in the event file and M is the current position of the BO in the event file. The adapter internally maintains a list of all the BOs within an event file including the status for each BO. The status of the BO can be either passed or failed. Once the status for each of the BOs is updated, all BOs for that event file are assumed to be processed, and the adapter archives the event file. Entries for all successfully processed BOs are deleted from the event table. However, failed entries are retained in the event table for reference. If the adapter is restarted while it is processing the BOs, it follows a recovery path that checks for all the processed (either passed or failed) and unprocessed BOs before the adapter was restarted. It gets the list of processed and unprocessed BOs based on the file name specified in the event id. Thus the adapter now has a list of all the successfully and unsuccessfully processed BOs as well as the list of unprocessed BOs. Therfore based on the the current architecture of the Flat-file Adapter is such that during inbound processing, when there is a file added to the event directory, the file gets Polled by the adapter. During polling process Adapter has a mechanism where it analysis the file to be polled, it calculates the total number of Bos present, and reads each Bo one by one. after each Bo in the file is polled there is an event ID generated in the database, in order to maintain the Status of the Bo (-1=failed,0=to be Processed and 1=Success)

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 29% of the total text.

Page 1 of 8

Method,Apparatus and architectural concept for determining the delta changes in File content Using Flat-File Adapter.

Problem with the Above method:

a)Since the number of Bos in the file are calculated and they are parsed in the order and also in the unordered way, User cannot add new Bos in to the File

b)calculating the number of Bos will need a run through in the file, which is a serious

performance Issue.

c)when there is a failure Bo, the Adapter runs back to the Bo in the file searching the location which is also a performance issue.

d)User cannot add a Bo of the same type, any where in the middle after the reading of the File Starts, User in the current scenario if he has to add a new Bo of same type, he has to add a new file which is a disadvantage.

d1).the new file should be gone through to get the number of Bos.

d2).the new file is polled only in the next poll cycle(because in the current poll cycle, file was not registered)this could be a delay based on the Speed of the System.

d3).the new file archiving is done, which is again a disadvantage, because if the same Bos are allowed to be accessed from the old File, only 1 file gets archived.

d4).The new file increases the number of files, which is also a maintainance problem.

PRIOR ART:

The Best thing is even other Adapters follow the similar method of considering File as an entity and parsing it, and not content of the file as entity
example :
as from the sources of Oracle Adapter Info-centre

http://download.oracle.com/docs/cd/E11036

_01/integrate.1013/b28994/adptr

file categorized and taken as an entity which is indivisible
In the case of debatching (multiple messages in a single file), messages from the first bad message to the end of the file are rejected. If each message has a unique separator and that separator is not part of any data, then rejection can be more fine-grained. In these cases, you can define a uniqueMessageSeparator in the schema element of the native schema to have the value of this unique message separator. This property controls how the adapter translator works when

parsing through multiple records in one file (debatching). This property enables recovery even

when detecting bad messages inside a large batch file; when a bad record is detected, the adapter translator skips to the next unique message separator boundary and continues from there. If you

1

_file.htm#CACHDJ

FF

Page 2 of 8

do not set this property, then all records that follow the errored record are also rejected.

The following schema file provides an example of using uniqueMessageSeparator.


<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:nxsd="http://xmlns.oracle.com/

p

cbpel/nxsd"

targetNamespace="http://TargetNamespace.com/Reader"

xmlns:tns="http://TargetNamespace.com/Reader"

elementFormDefault="qualified" attributeFormDefault="unqualified"

nxsd:encoding="US-ASCII" nxsd:stream="chars"

nxsd:version="

NXSD" nxsd:uniqueMessageSeparator="${eol}">

<xsd:element name="GUID" type="xsd...