External system interface method and system

• US 6,466,934 B2
• Filed: 05/11/2001
• Issued: 10/15/2002
• Est. Priority Date: 07/09/1999
• Status: Expired due to Term

• Current Assignee: Junot Systems, Inc.
• Original Assignee: Junot Systems, Inc.
• Inventors: Seese, David John, Burudgunte, Rakesh, Rodriguez, Eric Peter, Phillips, Darcy Wellington, Tan, Lee Yeh
• Primary Examiner(s): Corrielus, Jean M.
• Application Number:
  US09/853,229
• Publication Number:
  US 20010032206A1
• Time in Patent Office: 522 Days
• Field of Search: 707/4, 707/2, 707/3, 707/104, 707/102, 707/103, 707/8, 707/10, 707/201, 379/207.12, 379/246, 705/10, 709/217, 709/219, 709/315, 711/118, 711/117
• US Class Current: 707/703
• CPC Class Codes: G06F 16/9554 by using bar codes
• CPC Class Codes: Y10S 707/99932 Access augmentation or optimizing
• CPC Class Codes: Y10S 707/99933 Query processing, i.e. searching
• CPC Class Codes: Y10S 707/99934 Query formulation, input preparation, or translation
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99945 Object-oriented database structure processing
• CPC Class Codes: Y10S 707/99948 Application of database or data structure, e.g. distributed, multimedia, or image

Abstract

This invention relates to the field of interfaces between systems having data needs such as databases and input devices. Specific examples include SAP systems and bar-code readers. In general, these systems are referred to as “external systems.” A need exists for a method and system for providing an interface between external systems, such that the user of the external systems can configure an interface based solely on knowledge of the data in the external systems, without a need to have an in-depth understanding of the database model and communication protocols of each of the external systems. Therefore, according to one aspect of the invention, in an interface for communication with a first external system and a second external system, a method is provided for responding to an event, the event being related to communication with at least one of the first or the second external systems, the method comprising: receiving a message, the message comprising a metadata event key and a session identifier, the session identifier identifying a workset database for use with the message, the workset database having a workset database structure dependent upon metadata; and processing an action series dependent upon the metadata event key, wherein said processing is assigned to the session.

Claims

1. A method of querying a SAP system, the method comprising:

reading a list of tables, wherein the list of tables is dependent upon user-defined metadata;

reading a list of fields, wherein the list of fields is dependent upon user-defined metadata;

reading a list of “

where clauses”

, wherein the list of “

where clauses”

is dependent upon user-defined metadata;

building a message dependent upon said reading a list of tables, fields, and “

where clauses”

, and upon data from a workset database; and

sending a message to the “

query”

function module of SAP;

running the query function module, wherein the desired results of the query are provided to the message, wherein a modified message results; and

receiving the modified message.

2. A method as in claim 1 wherein said query function module comprises:

creating a list of fields to gather;

building where clauses for a main query;

determining fields to gather in main query, wherein the fields to gather in the main query comprise a subset of the list of fields to gather;

performing the main query by calling the RFC_READ_TABLE function of SAP;

receiving, a first table as a result of the RFC_READ_TABLE function describing the fields in the results of the main query and a second table as a result of the RFC_READ_TABLE function wherein the second table includes the results of the main query;

looping through the second table to parse out fields in the list of fields, wherein a set of parsed result fields is defined.

3. A method as in claim 2 wherein said performing step and said receiving step are repeated, resulting in a third table and a fourth table and further comprising:

looping through the fourth table to parse out the fields in the list of fields of the fourth table, and

adding the list of fields of the fourth table to the set of parsed result fields.

4. A method as in claim 3 wherein said preparing secondary where clauses is dependant upon results from a previous query.

5. A method as in claim 3 wherein said preparing secondary where clauses is dependant upon SY fields.

6. A system of querying a SAP system, the system comprising:

means for reading a list of tables, wherein the list of tables is dependent upon user-defined metadata;

means for reading a list of fields, wherein the list of fields is dependent upon user-defined metadata;

means for reading a list of “

where clauses”

, wherein the list of “

where clauses”

is dependent upon user-defined metadata;

means for building a message dependent upon said reading a list of tables, fields, and “

where clauses”

, and upon data from a workset database; and

means for sending the message to a “

query”

function module of SAP, wherein the message calls the query function module of SAP,

wherein the desired results of the query are provided to the message, wherein a modified message results; and

means for receiving the modified message.

7. A system as in claim 6 wherein said query function module comprises:

means for creating a list of fields to gather;

means for building where clauses for a main query;

means for determining fields to gather in main query, wherein the fields to gather in the main query comprise a subset of the list of fields to gather;

means for performing the main query by calling the RFC_READ_TABLE function of SAP;

means for receiving a first table as a result of the RFC_READ_TABLE function describing the fields in the results of the main query and a second table as a result of the RFC_READ_TABLE function wherein the second table includes the results of the main query;

means for looping through the second table to parse out fields in the list of fields, wherein a set of parsed result fields is defined.

8. A system as in claim 7 wherein said means for performing and said means for receiving repeat repeated, resulting in a third table and a fourth table and further comprising:

means for looping through the fourth table to parse out the fields in the list of fields of the fourth table, and

means for adding the list of fields of the fourth table to the set of parsed result fields.

9. A system as in claim 8 wherein said means for preparing secondary where clauses is dependant upon results from a previous query.

10. A system as in claim 8 wherein said means for preparing secondary where clauses is dependant upon SY fields.

11. A method of performing a SAP transaction, the method comprising:

reading a list of screens, fields, and key-press codes, and a SAP transaction code;

building a message, dependant upon the list of screens, fields, and key-press codes, the message comprising BDC data, the screens, fields, and key-press codes being metadata-dependant;

sending the message to SAP “

transaction”

function module;

running the transaction function module, wherein a modified message results, the modified message including diagnostic codes; and

receiving the modified message.

12. A method as in claim 11 wherein said transaction function module comprises:

calling the RFC_CALL_TRANSACTION function of SAP with a transaction code, and update mode, and transaction data in BDCDATA format;

receiving a return message.

13. A method as in claim 12 further comprising:

recognizing a message to save a data session in SAP; and

checking the return message for a failure code.

14. A method as in claim 13 wherein said failure code designates a failure of the RFC_CALL_TRANSACTION function, the method further comprising:

calling the BDC_OPEN_GROUP function of SAP;

calling the BDC_INSERT function of SAP using uses a transaction code and a set of transaction data of the failed calling of the RFC_CALL_TRANSACTION; and

calling the BDC_CLOSE_GROUP function of SAP;

wherein a stored session in SAP results.

15. A system of performing a SAP transaction, the system comprising:

means for reading a list of screens, fields, and key-press codes, and a SAP transaction code;

means for building a message, dependant upon the list of screens, fields, and key-press codes, the message comprising BDC data, the screens, fields, and key-press codes being metadata-dependant;

means for sending the message to SAP “

transaction”

function module;

means for running the transaction function module, wherein a modified message results, the modified message including diagnostic codes; and

means for receiving the modified message.

16. A system as in claim 15 wherein said transaction function module comprises:

means for calling the RFC_CALL_TRANSACTION function of SAP with a transaction code, and update mode, and transaction data in BDCDATA format;

means for receiving a return message.

17. A system as in claim 16 further comprising:

means for recognizing a message to save a data session in SAP; and

means for checking the return message for a failure code.

18. A system as in claim 17 wherein said failure code designates a failure of the RFC_CALL_TRANSACTION function, the system further comprising:

means for calling the BDC_OPEN_GROUP function of SAP;

means for calling the BDC_INSERT function of SAP using uses a transaction code and a set of transaction data of the failed calling of the RFC_CALL_TRANSACTION; and

means for calling the BDC_CLOSE_GROUP function of SAP;

wherein a stored session in SAP results.