Introduction
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:
- Give you an overview of the general PI concepts (you'll probably need a good SAP architectural/development understanding to keep up);
- Show you how to layout an integration, leveraging “pragmatic canonicals" and supporting Enterprise Services via PO;
- 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.....
- 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 developer.sap.com 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)
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 never one answer when it come to design, but there's always plenty of wrong ones!
Which #Workflow Inbox When? Pros and cons for SAP Business Workflow and SAP NetWeaver #BPM
