Skip to Content
A couple of weeks ago, I attended a CIDX standards group meeting – CIDX is the chemical industry’s standards organization. Like many of these groups they have an architecture team to address the technology direction that CIDX should follow.

One of the problems CIDX face is that they find using their current messaging standard for exchanging business documents, RosettaNet RNIF, is too expensive … especially for smaller companies.  Even RosettaNet itself admits that RNIF is expensive and so they have started their Multiple Messaging Systems Project to address the problem.

So what’s this got to do with T-Shirts?

Well one thing we did in the meeting, which I want to share, was to try and understand the nature of the problem better so that we could identify what sort of solution would be required to fix it. So we developed a table of style=”font-style: italic;”>Company T-Shirt sizes. Where the “T” in T-Shirt stands for technology and really describes the IT/Technology capabilities of different types of companies varying from “small” to “extra large”. Here’s what we developed …

T-Shirt Size
Extra Small (XS)
Somebody with just an email system and no ERP access. Perhaps just using spreadsheets. Can’t count on 7×24 connectivity or static IP address.
Small (S)
Company with simple stand-alone single-user ERP like QuickBooks. Can’t count on 7×24 connectivity or static IP address.
Medium (M)
Single company with multi-user networked ERP system. Little or no IT support.
Medium Large (ML)
Single company with multi-user networked ERP system. Able to install and configure software. Limited code “tweaking”.
Large (L)
Company with multi-user networked ERP system. Single company. Able to install and configure software. Can develop software effectively.
Extra Large (XL)
Potentially has multiple ERP systems, multiple geographies, multiple companies. Can develop software in-house or outsource. Extensive IT support.

So what’s the issue and what has this got to do with web services?

We concluded that you could never build automated links to XS companies but that you should be able to connect everyone else, i.e. from Small on up. Now most Extra Large and Large companies already have connections to each other that work, e.g. based on RNIF. However Large and Extra-Large companies do business with sometimes thousands of Small to Medium-Large companies and the lack of automated electronic connections requires that all the business documents they receive are entered into their systems manually … at high cost and with higher error rates.

Even web services, as currently defined, don’t really help as:

  • They are primarily designed to work over HTTP – small companies are not connected 7×24 and don’t usually have a static IP address,
  • Small, Medium and some Medium-Large companies usually don’t have the technical skills to configure a web service
  • Even if they could build or configure a web service, the connections to their existing backend/ERP systems don’t exist.

This means that, right now, only the Large and Extra Large companies can easily exchange business documents automatically.

So what’s needed?

Firstly you have to make web services work over non HTTP based approaches, e.g. eMail/SMTP. Next, you have to make the configuration of software for Small and Medium businesses automated somehow, e.g. using some version of WS-Policy, and finally, you have to have “shrink-wrapped” links to backend/ERP systems … we still have quite a way to go.

To report this post you need to login first.


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

  1. Former Member

    A nice weblog. I am not an expert with the Business Connector but so far as I remember, it allows webservices to be called using email. If a predefined structure of the message is followed, the webservices can receive data using SMTP. People may argue that BC follows a P-2-P model and is hard to maintain. Well, both P-2-P and hub-spoke model have their benefits as well as drawbacks. At least the XS sized companies can connect using the familiar email-based messaging systems while reducing costs and error rates.


    1. Former Member Post author
      Hi Shehryar

      I’m fairly new to SAP, so I am not sure what Business Connector does with web services and email … but I’m finding out and will let you know.

      But the real issue around this is lack of standardization and adoption around using web services over email. The client software that a small could use doesn’t exist … and as they don’t have the IT resources, they won’t be able to build one.


      1. Former Member

        Just checked the document SAP BC Developer Guide for Business Connector ver 4.7. In the section “Submitting an XML Document via Email” on page 372, the steps for using email-based messaging to invoke webservices are given.

        You are correct that the problem lies with standardization of such technologies and organizations have to rest with vendor supporting such means of communication.

        The client software can be any email client currently used by the organization to send requests and receive results from the invoked webservice. Yes…an ROI will definitely be required to adopt such process.


        1. Former Member Post author
          I’ve also been doing some checking, and I agree that the reference you give to BC does show you how to send or receive an XML document directly inside an email. But that’s not the same as web services.
          Web services require the use of SOAP headers as an envelope for the XML document. There is also a capability for handling SOAP in XI [1] that seems to allow the sending of messages using SMTP but not the receipt.
          But the real issue is that you can’t assume that your partner has SAP systems. This means have to have interoperability and there are no activities, for example in WS-I, that are working on this for SOAP over email. Without some agreement on how to make SOAP over email work in all the gory detail, vendors who make software for XS or S businesses would be reluctant to crete the connections as they probably wouldn’t work, or at best they would be different for each vendor they needed to connect to. It really sounds like a standards effort in this area is needed.



Leave a Reply