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:
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...
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:
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:
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
5 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 |