Skip to Content
Author's profile photo Matt Harding

How to be dangerous with PO/PI/XI 7.31 – Or Intro to PI 7.31 using an Enterprise Design Approach – Part 1


As our System Integrator “PI person” said just last week, (with me extrapolating just a tiny bit – artistic license!) usually a PI consultant gets on a project and are the lone ranger/wolf of NetWeaver integration on the project. They tend to have to solve unique problems with the latest SAP PI software (and concepts), while listening and complying to the customer Integration Architect who has little exposure to SAP oddness.  Plus to make things more demanding, they must build interfaces to tight and sometimes unrealistic timelines; while constantly training functional consultants to think about what they need and what 3rd parties can deliver rather than just expect 3rd parties/non-SAP systems to speak SAPenese!

In other words, there is usually little opportunity to really confirm they are implementing “best practice”, or even have the ability to figure out if there is a better way.

Luckily for him (kind of), he’s got me on the customer side with dangerous hands on knowledge of XI 3.0 but only SAP TechEd workshops and documentary knowledge of PI 7.31 to help push and pull him in different directions and to refactor the solution continually till we both agree we’ve come up with our “best practice”. So with PI becoming PO, or is it PrO (the marketing term which may need to be thought through) which is the JAVA only version of PI that integrates clunkily but easily enough with NetWeaver BPM; we explored the possibilities, looked at integration flows, NetWeaver Development Studio versus Swing client and this documents (roughly) our way forward.

So here’s my attempt to:

  1. Give you an overview of the general PI concepts (you’ll probably need a good SAP architectural/development understanding to keep up);
  2. Show you how to layout an integration, leveraging “pragmatic canonicals” and supporting Enterprise Services via PO;
  3. Put the design out there for true experts to try and tell me I’m doing things completely wrong 😉 I emphasize “try” as you need to realise I’m up for debating our current position…..
  4. Implement an overly simplistic example without some of the harder concepts like ABAP Proxies/IDocs/Guaranteed Delivery/Transporting objects/XSLT/User Defined Functions/etc; that you would still need to learn to really do much with PO not to forget to mention integration and building of BPM’s (you’ll be dangerous after this if you do this without learning the rest and practicing).

Note – I’ll deliver the last part in a secondary blog shortly (give me a few days)…

Accessing a PO system

This is the easy part – Just head over to and get yourself an Amazon Web Services instance of PO in about 10 minutes (provided you have an Amazon EC2 account already).  It’s currently a 7.31 SPS5 instance, and has all the tools you need to do what I’m about to explain. Steps to do this can be found here.

All the key Objects to Know (abbreviated and there are many more useful objects you should learn)

First, PO is made up of PI and BPM amongst other things; but key to implementing PI is setting up the System Landscape Directory with Software Component Versions (which belong to Products). These Software Component Versions (SWCV for short) effectively provide the breakdown of ownership of integration objects within PI, but you can think of it as software/service installations that come together to make a product (e.g. NetWeaver and ERP would be two separate SWCV’s).

Secondly, let’s talk about Data Types. These are effectively the structure of your message. Now you would think that would be sufficient to start connecting systems (if coming from a Business Connector world), but no…Now you need to put that message into a definition suitable to be exposed as a service. This is called a Message Type.

This Message Type can be mapped to, but cannot be used in an interface to a system outside of PO.  For that we need to add the message types to an operation(s) plus add interface meta data and this is called a Service Interface (You’ll see screen shots below that help with this but I’m trying to keep this short).

So with a Service Interface containing an Operation or Operations containing Message Type(s); which each contain their own Data Type – we’re good to start mapping but let’s point out a couple of more points…

  • Everything is arranged around those SWCV’s mentioned above; and then to organise this further, there are namespaces (like urn’s or url’s); and
  • Then dependencies between these SWCV’s need to be set-up to allow reuse between these different areas.  It’s not a big deal once you sort out your enterprise approach, but it can be annoying to beginners when you end up in cyclic dependencies (these are not supported).

The most important aspect here is to get the namespace right as these are the key to your objects within the runtime.

Anyway, moving on from that overly confusing aspect; now we need to cover message mappings.  These pretty much allow you to (can you guess)…map between 2 different message types.

You might think that’s everything but then the final step is the Operation Mapping. This effectively defines connected Service Interfaces and let’s you define what message mappings and other operations need to occur to get from one service interface to another service interface.

It’s overkill, and I never really understood the brilliance behind why so many layers, but it’s also not a big deal so let’s move on.

Now that was all what is known as Enterprise Services Repository set-up – Now we have PI Integration Designer (old Swing client’s Integration Directory) content to think through.

So back in the SLD, we need a Business System which requires a Technical System which requires products and associated SWCV’s to be installed.  In short, Technical System holds the physical information about a system (but not for interfacing communications with unfortunately) and Business Systems are the Logical version you talk about (kind of like how infrastructure providers like giving you hostnames that mean nothing (technical), so you name it something else (business)).

Why? Well for one reason, because of how we’ve used SWCV’s within the Service Registry, we now automatically know what can and can’t be done with these Business Systems; but also, the SLD doesn’t belong to PO (now days it is kind of more owned by Solution Manager) so that’s the way it’s got to be (though on a side note, the Landscape Management Database in SAP Solution Manager will probably take over one day).

So next is the coolest thing about PO compared to older PI; and that’s the Integration Flow.  Basically this is a single page model driven way of defining an interface including defining the associated:

  • Business System
  • Service Interface
  • Operation Mapping
  • Communication Channel Type and Configuration – This is effectively telling the integration what adapter to use, and what the parameters are such as security profiles, certificates, etc.
  • Receiver Determination (for message splitting/filtering) – e.g. This message if it contains this information goes here, otherwise it goes here.

For experienced PI people, the cool aspect of this model is that if you have a Service Interface with multiple Operations, you can represent this entirely within one model (surprised me when I saw this feature last week).

So in summary, the above is just a cheat sheet to hopefully help a little with the next sections.

Enterprise Design (for us at least)

PI Model.001.jpg

So here’s a picture of what we’ve ended up.  If you’re looking to learn PO, I’d recommend not reading this section just yet and to at least play with a PO system using Part 2 of this blog as a dodgy quick starter. 

The main point in this diagram is we have a “virtual” Product and SWCV called Global which is where we hold our Canonical definitions (and other helper objects). While we strive to use Enterprise Services and associated Global Data Types defined by SAP; we’re a small shop and mainly sticking with more customer specific Canonical definitions. The message types are business terminology and generic, but specific enough for the use case.  i.e.We won’t have one super customer that has everything in it for all types of customers but we will probably do that for employee until a use case comes out that goes way beyond a basic employee structure. 

For reference, the name space has global as part of it, and objects are held within functional areas (as opposed to process named areas which the business systems will leverage as they are independent of processes). Reusable components are in the same namespace with a .components appended to it.

So in short, nearly everything will map via a Canonical. This may mean a lot of double mapping (Sending system format to Canonical, then from Canonical to Receiving system format), but the benefits should outweigh this system overhead (and we’re not dealing with a throughput where performance will be a design issue).

So what else do we have..Well the sending and receiving systems own their own service interfaces (obviously), data types and have the responsibility of defining the mapping to the Canonical Message Type.

Then there’s the Integration Product which represents (and is installed on in the SLD) the PO system and contains Operations and Services.  Operations contains all interfaces (grouped around processes) in one place (for everything). It’s your one stop shop to see what your PI system is joining.  Services is a different SWCV with the sole purpose of allowing us to expose a service to anyone who has the right access. eg. We don’t want people calling ERP services directly (especially through firewalls), so we expose the service through PI.

Some of the rules that go along with this are:

  • Services SWCV should reuse Global message types unless it needs to be an exact representation of an external format (e.g. WSDL).
  • URN’s will be process based in the Services SWCV
  • Component will be appended to Canonical URN for helper “stuff”
  • Operation Mapping will be stored in URN’s associated with our level 2 process models that have been modelled by the business
  • For ABAP Proxies, only internal definitions are supported, hence Global Message Types should be imported (XSD) into the relevant ABAP SWCV and aligned with the ABAP namespace. e.g. This is a workaround as I’d prefer less data and message types but hey…
  • Every real SWCV (e.g. Not Global or Integration Product SWCV’s) is dependent on Global.
  • Integration Operations are dependent on all real SWCV’s.

Still to Come

Here’s the link to part 2 of this blog.

Calling all Lone Rangers/Wolves

Even in Expendables 2 (spoiler alert), Chuck Norris plays the ultimate “lone wolf”, and temporarily comes together with the others for a good cause/battle; so feel free to join me in this blog and rip apart the above and let me know why my pragmatic approach breaks too many EA rules, or Integration best practices…There’s neverone answer when it come to design, but there’s always plenty of wrong ones!

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Prateek Raj Srivastava
      Prateek Raj Srivastava

      Hi Matt,

      The first paragraph reminds me of almost all my project experiences. 😉 Going through your cheat sheet I thought I was reading "PI Development in a Nutshell". 🙂

      I have couple of comments for some of the statements:

      >>First, PO is made up of PI and BPM amongst other things; but key to implementing PI is setting up the System Landscape Directory with Software Component Versions.

      As an Integration Architect, I have experienced that if you begin the discussion with terms like SLD, ESR, the audience (Enterprise Architects, Functionals, Project Managers) loose their interest. I prefer beginning with the model-based approach first and then digging as deep as needed. For old PI, there were Integration Scenarios for this top-down model-driven approach. With PI 7.3 onwards, we have Integration Flows.

      >>So next is the coolest thing about PO compared to older PI; and that's the Integration Flow.

      Integration Flows are available since PI 7.3 (which is not PO); PO or PRO comprises of PI 7.3.1.

      >>So in short, nearly everything will map via a Canonical.

      Apart from the performance factor you already mentioned, it adds a point of failure and at times difficult to convince clients for this design.

      As I see, there are various possible ways of designing the repository landscape, some of the approaches are mentioned here by Thorsten Nordholm Søbirk and all of them have their advantages and disadvantages. I prefer to analyze the customer landscape first and recommend the appropriate design solution and I could never find one-suits-all approach.

      Thanks for the blog!

      Prateek Raj Srivastava

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Thanks for the real expert feedback Prateek as opposed to my governance architect with a bit of XI experience blog. I did target this blog more at ABAP'ers and people who know terms like SLD and Enterprise Services, but do take your point that a non-SAP person would struggle significantly with all of this information.

      In terms of PI 7.3 or PO; I'm really just targeting the JAVA only PI instance in my discussion, and in reality, the Integration Flow's are only really starting to hang together in the most recent releases (SPS6 even for comm channel reuse). But to your point, I didn't realise it was there earlier than 7.31 actually...

      Lastly about failure points with double mappings, while technically correct, I would argue the point that if you're system can speak canonicals, then there's no mapping (same as any interface), and if you're not, then at least when mapping you're dealing with mapping to an easy to understand message type rather than a target system's message type which is less prone to error. Overall, I'd propose this design for everyone and then tailor it based on interface scenario specifics like external facing aspects, performance, being used as an adapter and not an ESB, etc.

      My whole point of the Atlantis initiative some time back was to start with a position rather than the standard SAP answer of "it depends". It obviously does depend, but I think a position goes a long way to getting more commonality between customers and in the long run, better architectures. Also, good call to point out Thorsten's blog which is approximately the same as the above design, albeit without the Canonical definition or Enterprise Service SWCV. For reference, my biggest objective for this blog (from an enterprise design perspective), was to say - "this is the way to do it for small to medium (even large) installations using PI as an ESB and if there's better ways, let's discuss further...". And hopefully this may also help the non-SAP integration architect with a level of discussion to have so that the PI person doesn't just throw large numbers of interfaces into a single SWCV (sad to hear Thorsten has come across this)!

      Thanks again for the feedback,


      Author's profile photo Jocelyn Dart
      Jocelyn Dart

      So tempted to just put "it depends" 😉 !

      But I agree it's better to take a position, and yours seems a reasonable blend of pragmatism and idealism.

      And although the Integration Flows were there in their infancy for PI 7.3 it makes lots of sense to have PI connected to BPM, and my suspicion is that the clunky aspects are going to get a lot less clunky over time. Such as the first of these in 7.31 SP06 where we can now cross reference from the PI message to the BPM process and vice versa.

      Must confess that I much prefer the graphical flows in PI to the older Swing client too.

      Great work Matt!

      P.s. Would love to see some more diagrams though for the relationships between all of these objects - the more graphical the better.  Anyone out there with some favourites?

      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Thanks Jocelyn. I think upgrades for the next 12 month are going to be pretty important for PO customers if they commit to PO 7.31 in order to ensure they get all the kinks ironed out and for NWDS to catch up to SWING functionality. And I don't think for that, "it depends".

      Also, sounds like you're volunteering to sort out those diagrams?



      Author's profile photo Bhavesh Kantilal
      Bhavesh Kantilal


      looking at your reference to the acme product, canonical etc, I am venturing a guess that you come from a webMethods background. Having spent sometime on that side of the ESB world as well, I do think what you have articulated above makes sense..

      the problem in a PI landscape is almost always how you look at PI / PO etc. do you look at it as a pure ESB layer or look at it from as a  SAP centric integration layer. I have seen customers preferring components being named on the SAP process they are implementing (eg FI, CRM, SRM, Purchasing etc) but with the shift from PI to PO, I do prefer looking at it the way you are...

      keep it a 3 SWCV layer , depicting the services exposed to each end entity and so on. We ve been using this at our company for 7 years now and can definitely say that this model does work when PI is your primary layer of integration and SAP agnostic providing you with options to pull put data on your integration points in a seamless and easy way..



      Author's profile photo Matt Harding
      Matt Harding
      Blog Post Author

      Hi Bhavesh,

      Well my ACME is from Wild E. Coyote, but the Canonical is more about hanging out with people like Sascha Wenninger and Al Templeton too much who keep drilling into me software industry best practices and the like (though I did do some training in Webmethods many moons ago - some really nice tooling for that time BTW).

      Funny thing about PO, is you should look at it as an ESB, but it's not like most ESB's; which makes it hard to explain to people hung up on publish and subscribe ESB architectures; even though the pattern exists still in PO with some tweaking of the definition.  But that's not really addressing your question; and if you're just looking for a Business Connector replacement, then you could look at PO as this SAP centric Integration Layer, but considering the cost; it's a bit extreme to do that I think you would agree.

      Really good feedback also to hear you're having success with this model - it's still early days for us trying this out with the JAVA only PO but it's promising!