Some of you might have some objections against migrating your current ABAP & Java stack solution to a new single stack platform. This blog was created to show you benefits and describe hints how to manage some specific development/integration in a new environment. The world is changing and so is with SAP products. Don’t be afraid and enjoy using brand new solution.
At a beginning we’ll do a short comparison.
What are the features of a single stack?
- Light and robust
- Large file processing options (file-to-file)
- New monitoring tools
- Enhanced alerting concept
- BPM (required additional license or as a part of Process Orchestration)
- New development/configuration tools (NWDS)
What’s lost forever?
- ccBPM (replaced by BPM)
- ABAP monitoring tools (at least at our integration platform, but still you can use SXMB_MONI at your connected ERP or other SAP instances)
- ABAP adapters (IDOC, http)
Now let’s get back to our migration.
There is provided Directory Content Migration Tool, but to have a double check or just to jump into the newest tools(NWDS) you may consider that most of your migration tasks will be done manually.
First of all you have to analyze and catalogue all interfaces, integration scenarios etc…
In a general overview you’ll probably have to face two technical areas: Point to Point integration and ccBPM. Underneath we describe concept for each of this part.
1. Point to Point integration
As P2P integration we understand standard scenarios with outbound and inbound interfaces (fe. ABAP Proxy -> SOAP, FILE -> IDOC, RFC -> email etc…)
In this scenarios all we’ve got to do is:
a) move repository objects
b) recreate configuration (as ICO or full iFlow – with NWDS) – here you can use Directory Content Migration Tool (http://scn.sap.com/community/process-orchestration/blog/2012/11/19/moving-integration-directory-artifacts-from-dual-stack-to-single-stack)
2. ccBPM (also known as integration processes)
At single stack we don’t have an ABAP WF engine (on which ccBPM is working) so generally we’ve got 2 options to keep our integration working:
a) recreate integration processes as BPM flows
In this scenario we can assume that BPM works as an abstract part of ccBPM process and generally need to communicate with outer world using SAP PI.
b) eliminate integration processes with all possible single stack tricks and features.
When I remind right now my old expierience starting with ccBPM many years ago I feel (as usually) that right now I would completely change some of those solutions. Hope you’ve got the same feelings – it’s good because it means that you’re still evolving.
Back to the point: today probably I would replace half of those old ccBPM processes with other solution. On a new platform we can assume that there are even more technical possibilities to dump integration processes and replace them without loosing current functionality.
Underneath you’ll find some hints and options how to replace ccBPM processes functionalities:
- use asyn/sync capabilities with combination of RequestResponseBean and ResponseOnewayBean modules
- create message split, interface split to integrate with many target interfaces
- use java mappings to serve additional interfaces/communication
- create n-step integration with FILE adapter and local PI folders
Just to make it more clear underneath we’ll describe some examples in a specific situation.
IDOC to WS with files as backup.
In this scenario at PI we receive from ERP IDOC. In second step data is saved as FILE 1 at PI’s filesystem. Next we’ve got a synchronous WebService call and a response from WS is saved at filesystem as FILE 2.
After migration to single stack we might replace it with P2P integration.
In one action we save the file and send request to WebService. As source(IDOC) and FILE adapter are asynchronous we need to call WS using functionality of async-sync bridge (RequestResponseBean ResponseOnewayBean). The response of WebService is sent to a second FILE adapter.
It’s a typical example of IDOC collection and sending theme in one big bundle. You might find examples where you collect up to 5 IDOCs of a specific type or you wait for one hour and then send all in one message.
After migration we change it to a IDOC->FILE scenario and FILE->SOAP scenario.
At first FILE adapter (receiver) we probably will have to add each message to the same file. There are a lot of tricks you can use with a naming convention (fe. date/time manipulation). In a second step we upload a file with some mapping and send all data to WebService. The second FILE adapter may be scheduled in 1 hour frequency.