A Method and System for Resolving Issues Arising from Invocation Requests for Foreign Program Objects During Extract, Transform and Load Operations
Publication Date: 2014-Feb-25
The IP.com Prior Art Database
A method and system is disclosed for resolving issues arising from invocation requests for multiple foreign program objects during Extract, Transform and Load (ETL) operations by providing a single channel for collecting all invocation requests.
Page 01 of 5
A Method and System for Resolving Issues Arising from Invocation Requests for Foreign Program Objects During Extract , Transform and Load Operations
The need to invoke Foreign Program Objects (FPO) has dramatically increased in current software/application development industry. Moreover, a mature application capable of performing Extract, Transform and Load (ETL) operations generally provides an interface for each function unit in the mature application to interact with FPO. Two major issues arise due to enabling invocation of FPO at the level of function units.
The first issue is that FPO invoked by multiple function units can conflict with one another even if the same FPO works correctly when invoked individually. Consider a scenario wherein two teams working on the same project develop two different function units. Assume that the first team is working on a function unit of adding a random number to an existing integer value for creating a test ticket. One of the steps performed by the function unit includes invocation of a FPO for creating a random number based on a time seed. Further, assume the second team is working on another function unit to multiply existing integer value by time-seeded random number. A step performed by the other function unit also involves invoking the same FPO that was used for creating the random number based on the time seed. In such a situation a conflict occurs, which could result in reworking of code for each function unit. Further, the lack of a single channel for receiving all FPO invocations by all function units can result in redundant coding across different teams.
Secondly, during migration, either on a side of the mature application side, or on a side of the FPO, all function units calling FPO may have to be updated individually. For example a team creates lots of string operation functions in a FPO for creating test objects. Subsequently, when a new business logic that requires addition of a prefix "GSMRT Test Data:" to all test objects is introduced, code for each FPO needs to be modified.
Disclosed is a method and system for resolving issues arising from invocation requests for one or more FPO by one or more function units of an application program, by providing a single interface for collecting all invocation requests. The method and system collects all invocation requests using a Centralized Foreign Program Object (CFPO) plug-in. The method and system further uses the single interface for coupling the CFPO plug-in with the one or more function units. Figure 1 illustrates a business logic including the one or more function units.
Page 02 of 5
The method and system also builds and defines function extensions within the CFPO plugin for invoking the one or more FPO. Subsequently, when a function unit needs to invoke a FPO, the method and system enables the function unit to invoke the CFPO plugin. The method and system thereafter invokes the FPO using the function extensions...