Welcome to the XCS eiConsole Quick Tour demonstrating support for SAP IDoc formats. IDocs, or Intermediate Documents, are a popular vehicle for data exchange between SAP’s systems and other external applications or trading partners. Vast in number, these formats can be incredibly valuable assets in an integration environment. However, they can be difficult to consume as well as to construct. The PilotFish XCS eiConsole offers a paint-by-numbers approach for building, deploying, and maintaining any Interface” is synonymous with “Project”. Interfaces are the highest-level of visible abstraction within the eiConsole. Any given Interface is defined by one or more Routes. ” class=”lexicon-term”>interface. In addition, the XCS eiConsole offers a suite of capabilities that allow faster, better, more cost effective implementation of Interface” is synonymous with “Project”. Interfaces are the highest-level of visible abstraction within the eiConsole. Any given Interface is defined by one or more Routes. ” class=”lexicon-term”>interfaces into and out of an SAP environment using these IDoc formats. Over the next several minutes you’ll see just how this is accomplished.

The first screen that you see when you open the XCS eiConsole is the Route File Management window. It contains a catalogue of all of the Interfaces deployed to a developer’s working directory. Let’s take a look at one.

When you open an Interface you’ll see the eiConsole’s main Route Grid. This depicts the paint-by-numbers approach for deploying interfaces. It depicts the flow of data between a Source System and one or more Target Systems. The developer’s job is to move left to right through each one of these stages configuring the behavior appropriate for this interface.

In this case, we’re demonstrating information coming out of a Point of Sale System in an XML format that will be converted into an SAP Orders IDoc – basically a Purchase Order.

The first stage that is configured is the Listener. This describes how data will come into the environment. In this case we’ve configured information to be polled from a Directory. But the eiConsole supports a wide variety of inbound Transport options including everything from Directories, Web Services, and email, to HTTP, messaging middleware, and programmatic invocation. In each case you simply choose the Listener type appropriate for the Source System and then configure the corresponding configuration tabs.

After the data is accepted by the Listener there are Processors. This allows you to do general work over the data stream, such as Decryption, specialized Logging, or Authentication.

We then move on to the Source Transformation. This where data is taken from the proprietary format of the Source System and converted into a canonical model for this transaction. In our case, we’re using the inbound information “As Is” – that is it will be our canonical model. This is a Point of Sale XML representation.

We then move to the Routing stage. In the Routing stage if you had multiple Targets defined, you could define rules that would allow you to determine which one or which subset of these Target Systems to send the data to. Routing Rules can be defined through a number of means, the most common being XPath or Attribute based routing.

Also configured at the Routing stage are Transaction Monitors. Transaction Monitors are used to proactively notify the user of the XCS eiConsole and eiPlatform if something goes wrong. Error notifications can be sent via Email, SNPM Tra
p, or custom mechanisms.

Once you’ve determined which Target systems you need to send the data to, you’ll need to convert the data from your canonical format into the specific format of that Target system. That’s the job of the Target Transformation. In this case, the Target Transformation first converts data from your canonical XML format into an XML representation of an IDoc using your XSLT configuration. Next, that IDoc is laid out in the appropriate Fixed-Width file format mandated by SAP. The Delimited and Fixed-Width File Transformation Module takes care of that transformation from XML to a flat format.

The tool used to generate all logical mappings within the XCS eiConsole is the XCS Data Mapper. In the Data Mapper you’ll see that you have the Source Format on the left hand side, in this case the XML Purchase Order, and the TargetFormat on the right hand side, in this case SAP’s Orders05 Purchase Order IDoc. Through drag and drop you’ll then create the relationships between the Source and Target fields. Target data elements appear in green, Source data elements in blue.

In order to load in the Source and Target formats you’ll use the Format Readers. You’ll note that special support is provided for the SAP IDoc format. This allows you to take an IDoc description, export it from SAP in text format, and read it into the left or right hand side of the Data Mapper. This provides access, not only to the details of each field, but also any documentation associated with that field.

For those fields that use a set of enumerated codes, those codes are also available right within the XCS Data Mapper. All of this information is searchable to make the mapping process quick and painless.

Once you’ve logically mapped your data onto the IDoc format the next step is to turn it into that flat file format. The XCS File Specification Editor is the tool that’s used to convert data either to or from a Fixed-Width format into XML. You’ll see here that we’ve loaded in the logical structure of the Orders05 IDOC. As with the Data Mapper, SAP IDoc formats can be imported directly into this tool. However, any other Fixed-Width or Delimited structure can also be supported either through import…

Or manual definitions of fields and records.

Following the Target Transformation is the Transport stage. The Transport stage is used to define the connectivity between the eiPlatform and the Target System. Before you actually transmit the data you can apply Processors. Processors allow you to do things like post-validation and data cleanup.

Finally, the Transport Configuration allows you to define a Transport type. Once that’s been defined, to define the specific behavior of that Transport. In this case you’re simply dropping the data in a Directory.

Once the developer has finished configuring each one of the stages, including data transformations, the next step is to test the interface. When you switch to Testing Mode, you’ll see that all of the icons between the Source System and Target System turn to questions marks, indicating a stage of the test that you might choose to run.

You can choose to integration test any set of the stages together. In this case, you’ll start with the Source Transformation and allow it to run all the way through to the Final Transport. The arrows will indicate the stages that you’ll choose to run. When you click execute test, you’ll be prompted to provide a sample file. In this case, you’ll choose the XML representation of a Purchase Order that you wish to turn into an SAP IDoc.

When you click Open, as each stage of the test is run the question marks will turn into checkmarks to indicate success. If there had been a failure, you would have seen a red X.

You can then take a look at how the data appeared at each one of the stages. Here’s the Purchase Order XML that you chose to use as your input.

Your Source Transformation didn’t do anything with that data – it simply relayed it through to the Routing stage. The Routing stage relayed it to the one defined Target System, which included the Target Transformation. In the Target Transformation we mapped from that XML Purchase Order into the SAP Order05 IDoc format. You can see the IDoc name along with each segment and data fields.

We then moved on to the Delimited and Fixed-Width File Transformation Module, which consumes that XML and generates the correctly laid out IDoc format.

Finally, we move on to the Transport stage where some basic cleanup of the results is completed…

And the IDoc file is dropped in the appropriate directory. Once you’ve completed testing and are happy with the results you can return to the File Management window to select the interface and, if you’ve purchased the XCS eiPlatform, deploy that interface into a production environment. In addition to producing SAP IDoc documents, it should also be noted that the PilotFish software can consume any SAP IDoc format. The same File Specification Editor that you saw earlier, used to define a format that you wish to produce, can be used to consume an IDoc and generate an XML representation that you can map from. This concludes the demonstration of the XCS eiConsole, demonstrating support for SAP’s IDoc formats. You’ve seen how the XCS eiConsole provides a paint-by-numbers solution for producing or consuming any stock or customized IDoc format. For a more comprehensive hands-on look at how the XCS eiConsole supports IDocs, feel free to complete the corresponding Getting Started Tutorial. Thanks for listening and happy integrating!