Skip to Content

One of the most famous passages in Homer’s Iliad is the so-called Catalog of Ships that lists each of the contingents that set sail from the different cities and islands of Greece to join in the Trojan War.

The Catalog of Ships, which is greatly loved by Homeric scholars, is an inventory of political and military power in Greece long before the days of Socrates, Plato, and Aristotle. It names the king or hero who led each contingent, describes his home city, and provides the number of ships he contributed with the number of men in each ship.

This simple act of listing each leader and his contribution provides a fascinating glimpse into the coalition of forces that set out for Troy, their relative strengths and their relationships to the great powers of Late Bronze Age Greece.

No matter how powerful or weak each contingent was, together they formed a great coalition under a unified command to pursue a common cause: the siege and eventual conquest of Troy, a war that was to drag on for 10 years and inspire what many scholars consider to be history’s first true novel, rife with psychological drama and the tragic consequences of destructive emotions revealed on a human, rather than divine, scale.

Phew … now that really got my attention. If you’re interested in learning more about the Homeric Catalog of Ships, you can find it in Book 2, lines 494-759 of the Iliad. Go on … it’s good for you. And if you’re really interested … click the link to download a complete free copy of Thomas W. Allen’s classic 1862 study of history’s most literate inventory document entitled The Homeric Catalogue of Ships.

While I really enjoy reading and writing about Homer and his tragic Trojan heroes, the whole point of this literary interlude is that since earliest times, lists have been interesting and have helped move a story along. This particular list provides us a foundation to construct a picture of an entire expedition, which sets the backdrop and the stage for the story that unfolds. We can’t really understand the whole without learning something about each of its pieces.

In more prosaic terms, the list helps us integrate our vision.

Integration Vision

It’s the same thing with programming and developing interfaces. We have our vision of an integration architecture but we need to identify each of its pieces before we can begin building it. In other words, we need a list, our very own catalog of integration objects. It’s all part of our integration thinking.

Each piece can be described in detail and has a separate existence. But none has any real functionality on its own. They can only fulfill our integration requirement together, like the different contingents of the Achaean army setting sail from Greece so many many years ago.

We know what we want to do: extract payment reconciliation data from SAP and send it our banking partners through our EDI system. We also know that each partner expects his remittance data in his own unique file structure. And we know that we can leverage objects from our existing EDI architecture to make this work, as outlined in my previous posting Bank Payment Interfaces: Considering What We Have Is How We Begin.

And so we begin, to paraphrase and with sincere apologies to Homer, to sing, oh goddess, of the catalog that lists each object destined to become part of a whole that will unify our architecture and deliver remittance data from SAP to our banks.

I’ll just list the objects and requirements in this week’s posting. We’ll look at how they’re actually used in our next posting.

Extract Program Code

We’ve mentioned that we’ve found ourselves in an environment with an existing custom extract program based on standard SAP report RFCHKE00 that pulls payment data out of tables PAYR, REGUP and REGUH for one bank. We’ll keep this program since it can select for any bank or vendor set up in the system. We can use the existing selection logic for all our banks, since it pulls its data from PAYR but we will need to make some adjustments to handle the different formats for each specific bank.

Custom IDoc Message and Basic Type

The existing remittance program outputs its data to a file which is then sent to the bank by an SFTP batch file or script, which may or may not work once the consultants leave. Our approach is to replace the file in SAP with an IDoc to take advantage of:

     

  • Standard monitoring tools in the IDocs interface and in the Sterling Integrator (SI) EDI system.
  •  

  • Functioning outbound RFC calls through the RFC destination, file port, JCo, and the SI SAPSuite adapter, to send the remittance data out of SAP into SI.
  •  

  • Existing functionality in our generic EDI interface that is dependent on data from IDoc control segments to drive identification, translation, routing, and communications with our trading partners.
  •  

  • The STATUS interface from SI back to SAP to update the control and status records of the outbound IDoc with key processing milestones from the EDI system.

This is all about end-to-end visibility of the interface in SAP and SI. Any problems in outbound processing, particularly SFTP transmission, will be reported back to us immediately through the STATUS interface update of the control and status records of the outbound remittance IDoc.

So our approach is:

     

  • Build one custom IDoc message type for all remittance interfaces. Let’s call it ZAPREMIT. This is a one-time activity.
  •  

  • Build a custom IDoc basic type for each bank remittance. The data segments will be identical to the structure of the remittance file expected by the bank, which are all fairly simple. At most this will require one header, one to many data records with the same structure, and a trailer. Some banks skip the header. Each bank gets its own basic type. We can use the naming convention ZAPR01.

The following IDoc configuration is required:

     

  • Define IDoc message type — transaction WE81.
  •  

  • Link message type to basic type — transaction WE82.
  •  

  • Set the EDI partner profiles for your house bank — transaction FI12 in the IMG. The EDI partner number should be the same as the bank key. Without this, you can’t create a partner profile for the bank of Partner Type B. Of course, this assumes that the bank has been set up as a bank and not a customer or vendor.
  •  

  • Outbound partner profile for bank partner (Partner Type B) and message type and basic type.
  •  

  • Inbound partner profile for bank partner and STATUS IDoc. All partner profile keys for the STATUS IDoc, such as partner function or message code must match the outbound IDoc.
Custom Function to Pass Remittance Extract Data to IDoc

We’ll need to build a function module that will create our custom IDoc for each bank from the remittance extract data. We’ll pass unformatted 1,000 byte strings for the header and trailer records and an internal table with a single 1,000 byte field. This will handle any bank’s unique format.

The function will identify the bank and then build an IDoc that identifies the bank’s particular file structure through its basic type.

The function will be built once but adjusted to recognize the bank’s basic type each time a new bank interface is added. This should be a simple adjustment because the extract data is coming in unformatted one field structures that match the SDATA field of the IDoc data record. The only unique values that we really need to pass from bank to bank is the basic type name.

We can call the function Z_MASTER_IDOC_CREATE_ZAPREMIT.

SSH Profile For Each Bank in SI

All the information required to complete an SFTP put including hostname or IP address, port, user name and public keys. This is a one-time task for each bank and is critical for successful SFTP communications.

Entries in Custom SI Routing Table for Bank Interfaces

We’ll need two records for each bank interface in our custom table that manages EDI identification and routings in SI. These records will be entered each time a new bank is set up:

     

  • OB remittance interface by bank partner as receiver, message and basic type; and identifies the SSH profile ID, map, and communications BP to call at runtime.
  •  

  • IB STATUS interface by bank partner number as sender, and key IDoc control segment data required to get past the partner profile in SAP.
SI Map To Translate Remittance IDoc To Bank Flat File

This is a simple map to build since the IDoc basic type is already structured like the bank flat file. The map strips the control segment from the IDoc and ensures that each file record is the precise length required by the bank. One map is built for each bank.

New BPs In SI To Handle Bank Interface Processing

We’ll need two new BPs to process all bank interfaces:

     

  • The first BP identifies the bank partner and IDoc, the SSH profile ID, the map, and the communications BP. Then it runs the map to translate the IDoc to a flat file and calls the communications BP to kick of the SFTP. It also calls the standard EDI file archiving and the STATUS interface BP to report on the translation.
  •  

  • The communications BP uses the SSH profile to send the flat file by SFTP to the bank and calls the STATUS interface to report on the success or failure of the transmission.

The BPs are generic and use XPath statements to identify which bank interface is currently running and each of its specific parameters to run the map and send its file by SFTP. There’s no hard-coding anywhere so any bank remittance interface can be dropped into the architecture.

We’ll look at how this all works together in our next posting. Until then, I have a hankering to brush up on my Homer. And a Happy Valentines Day to everybody!

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply