Unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
An enterprise may incorporate several business systems to run its operations. Business systems may have business records that correspond, but are not identical, to each other. Various formats for communicating changes (“deltas”) of a business record in one business system with corresponding business record(s) in another business system have arisen. For example, Intermediate Documents is an interchange format that some business systems use, such as SAP® Enterprise Resource Planning (ERP). Another interchange format is called SAP® Enterprise Service Definition (ESD), which is a web services based format used by later developed business platforms such as SAP® Business ByDesign®.
Integration of business systems in an enterprise often involve incompatible business systems exchanging data that is common between such systems. A challenging area is the processing of different interchange formats to facilitate integrating different business systems such as SAP® ERP and SAP® Business ByDesign®.
In the following description, for purposes of explanation, numerous examples and specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be evident, however, to one skilled in the art that the present disclosure as defined by the claims may include some or all of the features in these examples alone or in combination with other features described below, and may further include modifications and equivalents of the features and concepts described herein.
Referring to
It is typical that the business systems in an enterprise may exchange data, such as customer data, inventory data, supplier data, and so on, with other systems. The exchange of data may be triggered for any of several reasons. For example, when the business record 112 is changed (e.g., customer information is updated, sales order is changed, etc.), corresponding data in another business system may need to be updated; the “update” process is sometimes referred to as “synchronizing” data between two systems. Thus, business system 102 may synchronize (“synch”) data with a business system 106, and vice versa; likewise, business system 104 may synch data with a business system 108, and so on.
Different messaging formats for the interchange of data between business systems have been developed. For example, business system 102 may communicate its changes to business system 106 in a message 132 using a format referred to a Intermediate Documents (IDOCs). Merely as an example, SAP® ERP is an enterprise resource planning (ERP) system that uses IDOCs. Business system 104 may communicate its changes to business system 108 in messages based on web services. For example, SAP® Business ByDesign® is a business platform that uses a web service format called SAP® Enterprise Service Definition (ESD). Messages may represent the entire business record or only portions of a business record. A message may include only those data fields in the represented business record that were changed; this configuration is referred to as a “delta transmission”; i.e., only the deltas (changes) made to the business record are transmitted. Alternatively, a message may include all data fields of the represented business record including changed data fields and unchanged data fields; this configuration is referred to as a “full transmission”; i.e., all the fields in the represented business record are transmitted.
In accordance with the present disclosure, the business system 102 may exchange data with business system 104 in the same manner as with business system 106, namely via a message 134 that is formatted in accordance with the interchange format understood by business system 102 (e.g., IDOCs). In this usage case, the business system 102 may be an earlier legacy system that communicates with a newer business system 104. In some embodiments, therefore, the business system 104 may include a handler 154 that receives a message 134 from business system 102 (“sending” business system) that is formatted in accordance with an interchange format that the sending business system understands. The handler 154 may update one or more elements of the business record 114 according to contents of the message 134. Conversely, in some embodiments, the handler 154 may generate a message 136 from data contained in business record 114 that is formatted in accordance with the interchange format understood by business system 102.
Referring to
Referring to
Without losing generality, a business record may be described as a collection of data that is organized in some structure of “data elements.” A data element may be deeply structured, comprising one or more data fields, one or more data elements, a combination of data fields and data elements, and so on.
The format of a message 134 (e.g.,
The message 134 may include an “ID” field which identifies the business record. The message 134 comprises data segments that represent the data elements of the business record. Without loss of generality, the data segments in message 134 may have the same structure as the business record it represents, and so the structure of the data segments in message 134 may be described by the tree structure representation depicted in
If the message 134 contains only those data elements of the represented business record 112 that have been modified, the message is referred to as a “delta transmission”. If the message 134 contains all of the data elements of the represented business record 112, the message is referred to as a “full transmission.” In either case, the message 134 itself may be referred to as a “delta message” because its purpose is to convey changes (“deltas”) in a represented business record, whether by full transmission or by delta transmission. Whether a delta message 134 is transmitted as a full transmission or a delta transmission may depend on the nature of the business record and on the particular business application running on the business system (e.g., business system 102) that prepares and sends the delta message. For example, some legacy business applications may only provide full transmission delta messages.
The delta message 134 depicted in TABLE I represents a delta transmission type delta message. Accordingly, data segments represent only those data elements in the represented business record 112 that are modified. Moreover, each data segment is associate with an operation code (“op code”) to indicate what kind of change was made to its associated data segment. For example, in an IDOCs formatted message, the operation code is referred to as a MSGFN code. In some embodiments, the operation codes that are handled may include: REPLACE, CHANGE, CREATE, UNCHANGED, and DELETE. Processing for each operation code will be discuss in more detail below.
The delta message 134 depicted in TABLE II below represents an example of a full transmission type delta message. The data segments in a full transmission delta message represent all of the data elements of the represented business record 112. There is only one operation code that is associated with the represented business record 112.
Still a third form of delta message is possible, and an example is illustrated in Table III below. This form of delta message is a full transmission delta message without delta handling capability. The message is similar to the type shown in TABLE II, but does not include an operation code. Some applications running on business system 102 may use this format of delta messages; for example a legacy application may only support this form of delta message.
The discussion will now turn to processing of a received delta message in accordance with principles of the present disclosure. In some embodiments, business system 104 may include handler 154 (
Consider, merely as an example, that business system 102 is an SAP® ERP system and business system 104 is an SAP® Business ByDesign® business platform. Suppose that a change is made in a business record 112 in the SAP® ERP system 102. Suppose further that the modified business record 112 is synchronized with a corresponding business record 114 in the SAP® Business ByDesign® business platform 104. The delta message 134 generated by the SAP® ERP system may be formatted according to the IDOCs format. On the other hand, the SAP® Business ByDesign® business platform 104 processes delta messages in the SAP® ESD format. Accordingly, handler 154 in the SAP® Business ByDesign business platform 104 may process a delta message 134 received from the SAP® ERP system 102 by mapping the IDOCs parameters in the received delta message into corresponding operations of an SAP® ESD delta message according the processing shown in
Referring then to
At step 602, a determination is made whether the business record (the “source business record”) identified in the delta message 134 maps to one or more “target business records” in the receiving business system 104. For example, the business system 104 may maintain a mapping table 202 which can be used to make this determination. It is noted that a business record 112 in business system 102 may map to one or more business records in business system 104. It will be understood that the phrase “target business record” mentioned in the following flow charts and description may refer to one or more target business records.
Continuing with
If the source business record does map to a target business record, then the data elements of the mapped target business record may be modified according to the following. In step 604, if a data element in the target business record (“target data element”) maps to a corresponding data element in the source business record (“source data element”), and if that source data element is NOT represented in the delta message 134 by a data segment (i.e., the whole data segment is missing), then that target data element is deleted from the target business record at step 614. Processing then continues as indicated by the flow to step 630. For example, step 604 may be repeated with other data elements of the target business record to determine if they need to be deleted.
Returning to
In step 608, if a data segment in the delta message does represent a source data element that maps to a data element in the target business record, then data fields comprising the target data element (if any) may be modified. In particular, if the data segment in the delta message 134 contains a segment field that maps to a data field in the target business record (i.e., the segment field represents a data field in the source business record that maps to a data field in the target business record), then in step 618 if the data contained in that segment field is a “no-data” operator (e.g., “/”), then the value in the data field in the target business record remains unchanged. Otherwise, the data field in the target business record may be updated in step 628 using the data contained in that segment field.
Returning to step 608 in
The discussion will now consider the processing by the handler 154 (
A data segment in the delta message 134 that is associated with an operation code of CREATE (e.g., an IDOCs delta message having a data segment associated with a MSGFN=009) may create data fields in the target business record. For example, if the data segment includes a segment field which maps to the target business record, then a data field in the target business record is instantiated. If a data field in the target business record has a mapping to the source business record but is not represented by a segment field, then the data field in the target business record is set to an initial data state. Processing then continues with remaining data segments in the received delta message 134.
A data segment in the delta message 134 that is associated with an operation code of CHANGE (e.g., an IDOCs delta message having a data segment associated with a MSGFN=004 or MSGFN=005) may modify data fields in the target business record. For example, if the data segment includes a segment field which represents a data field in the source business record that has a mapping to the target business record, then the data field in the target business record is updated according to the segment field. If a data field in the target business record has a mapping to the source business record but is not represented with a segment field, then the data field in the target business record is set to an initial data state. In some embodiments, an operation code of REPLACE is processed in the same manner. Processing then continues with remaining data segments in the received delta message 134.
A data segment in the delta message 134 that is associated with an operation code of UNCHANGED (e.g., an IDOCs delta message having a data segment associated with a MSGFN=018) may cause one or more data fields in a target business record to be created (instantiated). For example, suppose a data segment in the delta message represents a data field in the source business record that has a mapping to a data field in the target business record. However, if no such data field in the target business record is currently instantiated, then in some embodiments the data field may be instantiated in the target business record. Otherwise, if target business record already exists, then it remains unchanged. Processing then continues with remaining data segments in the received delta message 134.
The discussion will now consider the processing of a delta message of the type illustrated in TABLE III above, namely a full transmission without delta handling. As explained, a full transmission contains all of the data segments of the represented portion of business record 112, including modified and unmodified data segments. The “without delta handling” refers to the absence of an operation code from the delta message. In some embodiments, a full transmission delta message without delta handling may be processed by the handler 154 (
In some embodiments, the operation code associated with a data segment in a delta message applies to constituent data segments that are segment fields. Referring to
The discussion will now turn to generating an outbound delta message (e.g., 136,
In accordance with the present disclosure, when a business record 114 in business system 104 is modified, and that change is to be sent to business system 102, the handler 154 may process the business record in accordance with
First, it is noted that some (source) data elements in the (source) business record 114 may not have corresponding (target) data elements in the (target) business record 112. Thus, in a step 1102, if a source data element in the source business record 114 does not map to any target data element in a target business record 112 in business system 102, then the source data element is not included in the delta message 136, and processing proceeds continues at 1116. For example, to process data elements in the source business record 114. If on the other hand, the source data element does map to a target data element, then processing proceeds to step 1104.
If in step 1104, the modification to the source business record was the creation of source data element, then in step 1124 a data segment is added to the delta message 136 and associated with an operational code (e.g., MSGFN) of CREATE. Processing may then continue at 1116; e.g., for example, additional data elements in the source business record 114 may be processed.
If in step 1106, the modification to the source business record was the deletion of the source data element, then in step 1126 a data segment is added to the delta message 136 and associated with an operational code of DELETE. Processing may then continue at 1116; e.g., for example, additional data elements in the source business record 114 may be processed.
If in a step 1108, the source data element was not modified, then a data segment is added to the delta message 136 and associated with an operation code of UNCHANGED. Processing may then continue at 1116; e.g., for example, additional data elements in the source business record 114 may be processed.
The “Y” branch from step 1108 indicates that the source data element has been modified. Thus in a step 1110, if a data field in the source data element is mapped to a data field in the target business record (e.g., business record 112), then in a step 1130 a determination is made whether that data field was modified. If so, then in a step 1152, a corresponding segment field is added to the delta message 136 with the modified data. The segment field represents the data field in the target business record to which the data field in the source data element is mapped. Processing may then continue at 1116; e.g., for example, additional data elements in the source business record 114 may be processed. Otherwise, processing from the “N” branch of step 1130 proceeds to a step 1132, where a corresponding segment field is added to the delta message 136 with a “no-data” operator (e.g., “I”) to indicate that the value of the particular data field is not changed. Processing may then continue at 1116 to process the remainder of the source business record.
If in a step 1112, there is a data field in the target business record (e.g., business record 112) that is not mapped to any business records in the source business system (e.g., business system 104), then in some embodiments, a representative segment field may nonetheless be provided in the delta message 136. Accordingly, the step 1132 may performed to fill the segment field with a “no-data” operator. Processing may then continue at 1116 to process the remainder of the source business record.
If in a step 1114, there is data element in the target business record (e.g., business record 112) that is not mapped to any business records in the source business system (e.g., business system 104), then in some embodiments, a representative data segment may nonetheless provided in the delta message 136. Accordingly, in a step 1134 a data segment may be added to the delta message 136 and its constituent segment fields filled with “no-data” operators in order to avoid modifying the data values in the corresponding data element of the target business record. Processing may then continue at 1116 to process the remainder of the source business record.
Each computer (e.g., computer 1221) may be configured as a general purpose computing apparatus and may execute program code to perform any of the functions described herein. For example, business system 102 (
Each computer (e.g., computer 1221) includes, among its components, a processor component 1201 (comprising one or more processing units) operatively coupled to a communication interface 1204, a data storage device 1203, one or more input devices 1207, one or more output devices 1206, and a memory 1202. The communication interface 1204 may facilitate communication on the local network to access other systems, such as computer 1222 in business system 104 for example.
Input device(s) 1207 may include, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an Infra-Red (IR) port, a docking station, a touch screen, and so on. Input device(s) 1207 may be used, for example, to enter information into the computer. Output device(s) 1206 may include, for example, a display (e.g., a display screen), a speaker, a printer, and so on. Additional elements (not shown) may be including according to some embodiments.
The data storage device 1203 may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory 1202 may comprise Random Access Memory (RAM).
The data storage device 1203 may store program code 1212 which may be executed by the processor component 1201 to cause the computer to perform any one or more of the processes and methods described herein. In embodiments, for example, the program code 1212 in computer 1221 may be a business application executing in business system 102. Likewise, program code in computer 1222 may be a business application executing in business system 104. Embodiments are not limited to execution of these processes by a single apparatus.
The data storage device 1203 may store data structures 1214 such as object instance data, runtime objects, and any other data described herein. The data storage device 1203 may also store data and other program code for providing additional functionality and/or which are necessary for operation thereof, such as device drivers, operating system files, etc.
All systems and processes discussed herein may be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units. It will be appreciated that embodiments are not limited to any specific combination of hardware and software. Elements described herein as communicating with one another are directly or indirectly capable of communicating over any number of different systems for transferring data, including but not limited to shared memory communication, a local area network, a wide area network, a telephone network, a cellular network, a fiber-optic network, a satellite network, an infrared network, a radio frequency network, and any other type of network that may be used to transmit information between devices. Moreover, communication between systems may proceed over any one or more transmission protocols that are or become known, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP) and Wireless Application Protocol (WAP).
As mentioned above, in an illustrative embodiment the business system 102 may be an SAP® ERP business system and the business system 104 may be the SAP® Business ByDesign® business platform. The SAP® ERP business system implements delta handling based on the IDOCs format. The parameters of an IDOCs formatted delta message include a MSGFN parameter, which specifies the nature of the changes to a business record represented by the delta message. For example, in a full transmission message, the MSGFN parameter may be set to “005” that applies to the entire message. In a delta transmission delta message, any of a number of MSGFN codes may be associated with each data segment of the message. MSGFN codes include “003” for a DELETE operation, “004” for a CHANGE operation, “005” for a REPLACE operation, “009” for a DELETE operation, and “018” for an UNCHANGED operation. In addition to MSGFN, an IDOCs delta message may include a no-data operator, namely “/”.
The parameters in an SAP® ESD formatted delta message include an action code, a list complete transmission indicator (TRUE/FALSE), and an element controller. An action code may be associated with each data segment in the delta message and specify an action to be performed on the associated data segment. The action codes include 01 (CREATE), 02 (CHANGE), 03 (DELETE), 04 (SAVE), 05 (REMOVE), and 06 (NO ACTION).
The list completer transmission indicator (LCTI) indicates whether a list of similar child elements is being transmitted in the delta message. If LCTI is TRUE, all corresponding child elements in the list are transmitted. Child elements that are not transmitted in the delta message are implicitly regarded as deleted at the sender. If LCTI is FALSE, corresponding child elements in the list that are not transmitted are regarded as unchanged.
Delta messages in the SAP® ESD format are expressed in Extended Markup Language (XML). The “element controller” aspect of the delta message provides extended XML handling for interface operations for passing additional element information between the delta message and a proxy. For outbound messages, the element controller may:
Examples of SAP® ESD formatted delta messages are shown in
In embodiments, an IDOCs delta message received by the SAP® Business ByDesign® business platform 104 may be processed by mapping the IDOCs message pattern to operations corresponding to SAP® ESD message patterns. Similarly, embodiments may generate an IDOCs formatted delta message in the SAP® Business ByDesign® business platform 104 by mapping the SAP® ESD message pattern to operations corresponding to IDOCs message patterns.
The above description illustrates various embodiments of the present disclosure along with examples of how aspects of the present disclosure may be implemented. The above examples and embodiments should not be deemed to be the only embodiments, and are presented to illustrate the flexibility and advantages of the present disclosure as defined by the following claims. Based on the above disclosure and the following claims, other arrangements, embodiments, implementations and equivalents will be evident to those skilled in the art and may be employed without departing from the spirit and scope of the disclosure as defined by the claims.