Skip to main content

IDoc Whisperer | Bridging the Gap Between System A and B with Magical Data Exchanges [Part 1]

Once upon a time in a company named Ashish Enterprise, they had two SAP systems - System A and System B. The business processes in Ashish Enterprise required seamless integration between these systems to exchange data in real-time. To accomplish this, they decided to implement IDocs (Intermediate Documents).

In their SAP landscape, System A was responsible for managing the sales process, while System B handled the production and manufacturing activities. The company needed to ensure that sales orders created in System A were immediately transmitted to System B for timely production planning and execution.


To set up the IDoc integration between System A and System B, the following steps were taken:


  • Partner Profile Configuration:

            Partner profile configuration is a crucial step in setting up the IDoc integration between systems.             It involves defining the communication settings and parameters for each partner involved in the             IDoc exchange. In this case, we'll focus on configuring the partner profiles for System A and                System B.

            Here are the steps involved in partner profile configuration:

                a. Accessing Partner Profile Configuration:

                        In System A, go to transaction code WE20 (Partner Profile) to access the partner profile                         configuration.

                        In System B, also use transaction code WE20 to access the partner profile configuration.

                b. Creating a Partner Profile:

                        In System A:

                            Click on "Create" to create a new partner profile for System B.

                            Enter the partner number for System B. This number uniquely identifies System B in                             the partner profile configuration.

                            Set the partner type based on the role of System B (e.g., "LS" for Logical System).

                            Enter the logical system name for System B (e.g., "SAP02") in the "Partner Number"                             field.

                           Configure other relevant fields based on the specific requirements of the integration,                                such as message type, port settings, and process code.

                           Save the partner profile.

                        In System B:

                            Follow the same steps as above but create a partner profile for System A.

                            Specify the partner number for System A, logical system name (e.g., "SAP01"), and                                other relevant details.

                c. Configuring Communication Parameters:

                           In both System A and System B:

                           Access the partner profile created for the respective system.

                           Configure the communication parameters to establish the connection between the                                   systems.

                           Specify the communication method, such as RFC (Remote Function Call) or other                                   supported methods.

                           Provide the RFC destination, which represents the connection details of the target                                   system.

                           Set the host name and port number of the target system.

                           Define the communication protocol (e.g., TCP/IP, HTTP, or HTTPS).

                           Additional parameters such as encryption or compression settings may also be                                       configured based on the specific requirements.

               d. Defining Message Types and Settings:

                       In both System A and System B:

                       Access the partner profile for the respective system.

                       Define the message type(s) associated with the integration scenario. For example, in                               System A, specify the message type for sales orders, and in System B, specify the                                   message type for production orders.

                       Configure the specific settings for each message type, including the IDoc structure,                                segments, fields, and any additional parameters required for the integration.

                        Configuring IDOCS with screenshots

  • Communication Channels:

            The SAP Basis administrator defined the communication channels for IDoc exchange. They set             up communication methods, such as RFC (Remote Function Call), to establish the connection                between the two systems. They configured the communication parameters, including the RFC                destination, host name, port number, and other necessary details.

  • Message Type Definition:

            In both System A and System B, the SAP functional consultants defined the IDoc message types             required for the integration. They specified the structure and content of the IDocs, including the             segments and fields to be included. For example, they created a message type for sales orders in             System A and a corresponding message type in System B to receive the sales orders.

  • Mapping and Transformation:

            The functional consultants designed mappings and transformations between the source and                    target IDoc structures. They ensured that the data from System A's sales order IDoc was                        correctly mapped to System B's IDoc structure for production planning and execution. They                    configured field mappings, conversions, and validations to ensure data integrity and                                compatibility.

  • Testing and Validation:

            Once the setup was complete, the SAP Basis administrator and functional consultants performed             extensive testing and validation. They created test sales orders in System A and monitored the                IDoc flow to System B. They verified that the IDocs were transmitted successfully and that the             sales orders were accurately processed in System B.

The IDoc integration between System A and System B was crucial for Ashish Enterprise because it facilitated real-time data exchange and streamlined their sales and production processes. With IDocs, they could ensure that sales orders were promptly transmitted to the production department for immediate planning and execution, reducing lead times and enhancing customer satisfaction.

IDocs provided a reliable and standardized method for exchanging data between SAP systems, improving efficiency, data consistency, and process automation. By automating the data flow using IDocs, Ashish Enterprise could enhance their overall business operations, reduce manual effort, and achieve better integration between their systems.

And so, with the successful implementation of IDocs, Ashish Enterprise enjoyed seamless data exchange and efficient business processes between System A and System B, bringing harmony to their SAP landscape.

Liked the story ? Stay tuned to know all about IDOCs.


Comments

You might find these interesting

8 Must-Know Questions About Object Store on SAP Business Technology Platform

What is the problem that Object Store solves ? Modern enterprise systems increasingly deal with massive volumes of unstructured data such as documents, logs, media files, and backups. Traditional relational databases are not optimized for such workloads. What is Object Store ? Object storage—commonly referred to as blob storage—addresses this gap by providing scalable, durable, and cost-efficient storage for unstructured data. Object storage is a storage architecture designed to manage unstructured data as discrete units called objects.  Each object consists of: Binary data (file content) : Image , File etc Metadata (descriptive attributes) : File size, Content type, Last modified timestamp, Storage class (hot, cool, archive) Unique identifier (key or URL) : unique path-like string used to locate a blob inside a bucket Unlike file systems or relational databases, object storage does not rely on hierarchical file structures or schemas. The SAP BTP Object Store service is a managed, ...