Patent Application
20050278347
Embodiments of the present invention relate to a flexible and easily extendable software architecture for converting data from a given user's format into various receiver-specific formats, and/or from various sender-specific formats into the user's format.
Many businesses and other organizations exchange electronically-stored data. One example is the exchange of data between banks and their customers. Customers might send payments, among other kinds of data, to their banks in files stored electronically on machine-readable media, such as floppy disk or magnetic tape. The banks might, in return, send bank statements to their customers in electronically-stored files.
The data that needs to be supplied in such exchanges may have format requirements that vary widely. That is, different banks may set respective different protocols as to data type, content, organization and so on.
Complying with these various different protocols can be burdensome to the businesses and other organizations. This may be especially true when businesses expand and therefore have dealings with new banks. Business software exists for assisting businesses in complying with the various protocols, but such software may lack a flexible and easily extendable architecture. That is, known software may require laborious, unwieldy and error-prone “hard-coding” to accommodate new banking relationships and/or changes in the data formatting requirements in existing banking relationships. An improved approach is needed in view of the foregoing considerations.
Embodiments of the present invention relate to a flexible and easily extendable architecture for software to format data for exchanges of electronic data. The architecture may separate general operations from format-specific operations. More particularly, the software may comprise a general engine to call one of a plurality of format-specific data conversion program modules. Each format-specific data conversion program module may comprise logic to convert a format of user data into a format required by a specific receiver, such as a bank, and logic to convert a format of sender data, such as data sent by a bank, into a format of the user. More specifically, the logic may be provided in a common set of methods that can be called by the general engine. The engine may handle supporting operations for the format-specific program modules, such as file handling operations, but have no format-specific information. By separating general operations from format-specific operations in the foregoing way, new data conversion requirements can be easily accommodated by simply coding a corresponding new format-specific program module, rather than substantially re-coding a more monolithic block of code.
In the example of
In embodiments, the database 105 may be an SAP Business One database. SAP Business One is a known business software package designed by SAP Aktiengesellschaft for small-to-midsize companies that provides such capabilities such as accounting, reporting, financial management, inventory management and logistics, and sales force automation. The engine 100 may be implemented, for example, as an “add-on” to existing SAP Business One software, and be called or invoked from within, and/or by, the SAP Business One software. The SAP Business One software and add-on may execute within a networked client/server system, and stand in a server relationship with respect to various clients. More specifically, for example, the database 105 may be accessed via a network server using a database management system such as Microsoft SQL Server. For illustrative purposes, the description hereafter will refer to embodiments of the present invention as applied within a SAP Business One environment. However, it should be understood that the embodiments could be applied in other settings.
In embodiments, each module 101 could be a DLL (dynamic load library) or “executable” that executes in a Windows® operating system environment. Referring now to
Notwithstanding their common structure, each module 101 is, as noted earlier, format-specific. That is, each has logic corresponding to a specific receiver/sender, where the receiver and the sender are the same (such as the same bank). Thus, format-specific program module 1 could have logic corresponding to Bank 1, format-specific program module 2 could have logic corresponding to Bank 2, and so on. When data was received from Bank 1 or needed to be sent to Bank 1, format-specific program module 1 would be invoked to perform the necessary data conversion; when data was received from Bank 2 or needed to be sent to Bank 2, format-specific program module 2 would be invoked to perform the necessary data conversion, and so on.
An example of the operation of the outbound method is discussed in more detail below. Referring to
Assume that by reading the Payment methods object 401a the engine 100 determines that that format-specific program module 2 (see
The standard array is “standard” in that, although its specific content will correspond to a specific receiver, the content is of a kind that is required for a broad range of receivers. For example, most banks receiving a payment might require a customer name, an account number, and a payment amount, and these are examples of kinds of data that might be included in the standard array 402.
The pointer 403 may be used by the outbound method to access data required by a receiver but not present in the standard array. For example, suppose that for a particular user of the present invention, a particular bank (say, Bank 2 as in the present example) needed an address of a customer in addition to, say, a customer name, account number and payment amount. Further suppose that the standard array contained the customer number, name, and payment amount, but not the address of the customer. The outbound method might use the pointer to access the database to obtain the address of the customer and provide it for formatting and writing to the output file.
According to embodiments, the pointer 403 may be used to access data as follows. An SAP Business One API (Application Programmer's Interface) 405 may provide for accessing data on the SAP Business One database 105 through the mechanism of creating specific instances of objects corresponding to the database and to objects on the database. For example, reference number 406 in the API 405 indicates an instance of a database object corresponding to database 105. Reference number 406c indicates an instance in the API 405 of the Customer object 401c on the database 105, reference number 406d indicates an instance in the API 405 of the Invoices object 401d on the database 105, and reference number 406e indicates an instance in the API 405 of the Products object 401e on the database 105. The instances in the API can be used to access corresponding objects on the database 105.
More specifically, instantiated objects 406, 406c, 406d and 406e may be COM (Component Object Model) objects. COM is a software architecture developed by Microsoft® to build component-based applications. COM objects are discrete components, each with a unique identity, which expose interfaces that allow applications and other components to access their features.
In view of the above discussion, the pointer 403 may more particularly be a pointer to the instantiated COM database object 406. The engine 100 may initially instantiate the COM database object 406 in the API 405 and pass the pointer 403 to the outbound method 301. The outbound method can then use the instance of the database object 406 to instantiate other objects in the API 405. Thus, returning to the above example, the outbound method might use the pointer 403 to access the instantiated database object 406, and through the instantiated database object 406, create an instance of the Customer object 406c in the API 405. The outbound method 301 might then call methods in the instantiated Customer object 406c to access data associated with the corresponding Customer object 401c on the database 105. For example, the outbound method 301 might call a “read” method of the instantiated Customer object 406c in the API 405 to read an address of a customer associated with the Customer object 401c on the database 105. The instances 406d and 406e might be used in a similar manner.
The pointer feature described above is a further contributor to the flexibility and extendability provided by the present invention. Most or all of the data needed by a receiver will be provided in the standard array, and it is preferable to avoid modifying the standard array in order to maintain compatibility with as many receivers as possible. With the pointer, the need to modify the standard array for random unconventional requirements that may arise from time to time among various existing or new receivers is avoided. Instead, these random unconventional needs can be easily accommodated by providing access via the pointer directly to the user data.
More fundamentally, flexibility and extendability is, as noted earlier, enabled by the separation of the functionality of the engine from the functionality of the data conversion modules. More specifically, the engine provides base class support for the modules, while the modules only handle data conversion. For example, the engine performs basic file handling functionality in support of the modules. In a Windows® environment, for example, the engine might perform such functions as creating a new output file 103 for writing data converted by the module, opening the file, closing it, assigning it to a specific folder, saving it on disk, and so on. The modules, therefore, need not handle any of the details of file handling or other aspects of interfacing with an operating system. Accordingly, the coding of the modules is simplified and only needs to address data formatting requirements.
The inbound method 302 is discussed next, with reference to elements in
The inbound method operates similarly to the outbound method. Like the outbound method, the inbound method is called by the engine, which passes the inbound method a standard array 402 and a pointer 403. However, in contrast to the outbound method, the inbound method may not be called by the engine until after the engine calls the dimension determining method 303 to determine the dimension (number of records) of an incoming file. The dimension determining method 303 may need to be executed because the data being converted is not internally generated, as by contrast is the case with the outbound method. Therefore, the engine, which writes the converted data 205 for the inbound method via the SAP Business One API 405, must learn from the dimension determining method how big the incoming file 200 (e.g, how many payment transactions the incoming file includes) so as to create a temporary engine internal buffer 410 that can accommodate it. The dimension determining method, as a method of a format-specific data conversion module 101 tailored to the sender 201, has knowledge about the specific format of the incoming file from the sender and thus can determine its dimension.
After the dimension determining method determines the dimension of the incoming file, it passes the dimension to the engine, which creates a corresponding standard array 402 and reads unconverted data 204 from the incoming file 200 on the file system 108 into the standard array. The engine calls the inbound method, passing it the standard array 402 and a pointer 403 to access the user database for information needed but not in the standard array. The inbound method processes the incoming data stored in the standard array. If data is needed by the inbound method but not present in the standard array, the inbound method may use the pointer to read data on the SAP Business One database 105. The inbound method converts the data 204 from the incoming file (passed via the standard array as a data container) to a format that can be handled by SAP Business One, and returns converted data 205 to the engine. To apply the converted data 205 to the SAP Business One database, the engine may create an instance of an object of the SAP Business One API containing methods for writing the converted data to the database, and execute the methods.
In view of the above,
As shown in block 502, the outbound method may convert the user data and return converted data to the engine. As shown in block 503, the engine may create an output file and write the converted data in the output file.
As shown in block 507, the inbound method may convert the sender data and return it to the engine. As shown in block 508, the engine may write the converted data in the SAP Business One database.
Embodiments of the present invention may further relate to data conversion for reporting foreign trade activities. Governments of countries typically require foreign businesses that conduct trade in the countries to report their activities to respective foreign trade offices of the countries. Like banks and their associated financial data, different countries may have different respective format requirements for foreign trade reporting data. To meet such requirements, embodiments of the present invention may comprise a plurality of format-specific data conversion modules and an engine to call the modules and provide supporting functions as described above. Each format-specific module contains logic for converting outgoing data into the format required by a specific country. For example, one format-specific module might contain logic for converting foreign trade reporting data according to the format requirements of the foreign trade office of Brazil, while another format-specific module might contain logic for converting foreign trade reporting data according to the format requirements of the foreign trade office of Sweden, and so on. The modules may contain outbound methods but not inbound methods, since there is typically no reciprocal sending of data from the foreign trade offices.
A computer program or collection of programs comprising computer-executable instructions according to embodiments of the present invention may be stored and transported on machine-readable media such as diskette 601, CD-ROM 602, magnetic tape 603 and fixed disk 604. The computer instructions may be retrieved from the machine-readable media 601-604 using their respective reading devices 605-608 into memory 600, and executed by a processor 610. The functionality disclosed hereinabove for performing the embodiments may find specific implementations in a variety of forms, which are considered to be within the abilities of a programmer of ordinary skill in the art after having reviewed the specification.
Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
