Skip to Content

I was recently lucky enough to play a small part in a XI implmentation which constituted mainly a B2B landscape. At first it was a big pool of muddy water but as time moved the dirt settled, and the sour turned sweet. In the following read I will share with you some of the insights I gained about the much sought B2B scenarios and the hyped ‘Party’.

A ‘B2B scenario‘ and the first thing that comes to our mind is ‘Party‘. This is one thing that distinguishes a A2A from B2B.

Lets look into a sample ‘Party’ and the attribute it can have;

image

By default for the Agency, in the drop down menu we have;  · 016 – for Dun & Bradstreet Corporation  · 009 – for EAN – International Article Numbering Association  · 166 – for NMFTA – National Motor Freight Traffic Association  Lets talk about DUNS (more details). It is a 9 digit number unique for a business entity. So a DUNS entry in a party will make it unique in the system landscape.   Similarly we have EAN (more details) and NMFTA.

But unlike the standard options we have in the drop down menu for the agency we can also have others that can be keyed in, say ITU (International Telecommunication Union) and its scheme X.400, an OSI standard for exchange of messages. This entry is usually seen in case of a EDIFACT implementation (SeeBurger adapter).  Even entries for the partner profile involving the partner number can be made (ALE#LI) and in this case the ‘Name’ will be of length 10 (prefix 0’s to adjust). 

Now each ‘Party’ will also have a service under it and the corresponding communication channel to connect to the system of the other business (RNIF, EDIFACT, MAIL, FILE etc).

image

Another interesting thing is the ‘Virtual Receiver’ found in the Receiver Determination and the Sender Agreements that distinguishes a B2B from an A2A scenario.

image

image

This option for a Virtual Receiver will be necessary at the point of interface where a trasfer of data is perceived from the external system to our customer/client system (mostly SAP) ie in other words the point of integration of the external systems. So if your client’s SAP system is sending data you would’nt find a virtual receiver option in your sender agreement but if the external business is interacting virtual receiver is used. 

To avoid confusion on where to use Virtual Receiver, its advisable to use an integration scenario and then simulate your Configuration, say as in case of Rosettanet scenarios.  Rosettanet Software component comes with predelivered content consisting of Integration scenarios. While in your configuration you simulate your CS from the IS, the entries specified takes care of the Virtual Receiver settings. 

A Screenshot:

image

And then when you thought that was all …  We come to Security .. the buzzword when two business interact and communicate and this is what we will get to see often in B2B scenarios, some at the Adapter level and some at the Receiver agreement level.  The following screenshot shows how cetificates etc can be enforced. 

In Receiver Agreement level:

image

In the Adapter:

image

Well, these are some points I thought I would share with you. Maybe there is more to the whole scene and I would suggest fellow SDNers to share their thoughts on B2B implementation as a blog or as valuable comments to this blog.


To report this post you need to login first.

7 Comments

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

  1. Dirk Deberlanger
    Hi Shabarish,

    It starts out very good but I would have preferred also an explanation of why you would use virtual receiver and what effect it has exactly on the remainder of the scenario ( instead of ‘test it yourself’… ).

    regards
    Dirk

    (0) 
  2. Abhishek Srivastava
    Hi,
    You mentioned that scheme to be ALE#LI in this blog, while in the other (Wanna Party) you mentioned it to be ALE#KU. Does this make any difference? If yes, can you please tell?

    ~Thanks.

    (0) 

Leave a Reply