Reducing integration effort by leveraging SAP enterprise services part1Posted: February 1, 2014 Filed under: SAP, SAP ABAP | Tags: SAP ABAP, SAP PI, SAP PO Leave a comment
From my post on SCN – http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/04/reducing-integration-effort-by-leveraging-sap-enterprise-services
The motivation of the blog is a conversation I had with couple of friends. They had implemented a new SAP functionality but were hassled by the amount of effort spent in integration. They eventually completed the task but after lots of crazy hours on late nights and sometimes weekends. As both the integration as well as the functional person is a friend and didn’t know about using enterprise services, I realised that perhaps not everyone is using enterprise services. Further, I was designing and implementing a solution to integrate SAP ECC with an external application for managing distributors and thought to write this post. Our integration required sending master data from SAP and transactional data updates in SAP ECC in OTC / P2P process area triggered from the external application.
Starting with the basics, look at the definition from SAP from BBA guide.
Enterprise Services: Web services using a common enterprise data model based on process components, business objects, and global data types, and following consistent communication patterns. SAP exposes software functionality as enterprise services.
There’s good documentation at http://esworkplace.sap.com/ .
In integration world, I see them as equivalent of classes in application development. If you’re able to use pre-existing content, most of the work is already done for you.
Why to go for enterprise services instead of trying to build them from scratch – what are the practical benefits?
– Leverages pre-built solutions reducing in substantial development effort reductions. We were able to reduce development effort to around 60% of initial estimates and even this is high because of the first time efforts in understanding their architecture and doing some prototyping.
– Easy to extend: Any project will require customization not delivered by standard solution and normally making changes later on is very time-consuming. Most of the functionality is already covered and even if additional changes are required – SAP has given a nice framework to customize them first in PI and then carry out adjustments on SAP system in ABAP stack.
– Comes with a lot of bells and whistles: Have error handling, data validation pre-built.
The following points need to be considered though:
– We utilised various software component versions and there were two mechanisms to get them installed in our landscape.
a) Some require installation of an add-on in ECC requiring BASIS effort (e.g. ECC-SE add-on to be installed by BASIS).
b) Others require activation of irreversible business functions (e.g. ESOA_OPS01 for services in SAP APPL). It’s important to understand that some of the business functions can’t be reversed and hence some amount of regression testing of affected areas need to be performed. SAP provides a test catalogue about the impacted functionality which can help in determining the impact. We tried them first in sandbox. Initially the activation didn’t go smoothly resulting in ABAP dumps which go away on activation. However, it’s painful as you have to wait for a transaction to dump before activating it. After an OSS message, finally we regenerated all programs of EA-APPL, ECC-SE and SAP_APPL software components.
At a very broad level, there are 5 different activities that need to be done.
i ) Identify which services meet requirements completely ( or to the largest possible extent ). There can be more than one service for a given business function ( e.g SalesOrderERPCreateRequestConfirmation_In_V1 and SalesOrderERPCreateRequestConfirmation_In_V2 for sales order creation ). I noticed two things: The former wasn’t able to meet all our requirements and has been deprecated as well. Like any other artefact in software engineering it’s best to avoid deprecated services.
ii) PI configuration: This was straight forward in our case as it was simple SOAP to proxy and reverse.
iii) Back end ABAP adjustments: These were made to fill in organizational data as the third party system doesn’t have concept of some of the organisational structure, data etc.
iv) BASIS activities: Installation of add-ons (e.g. ECC-SE add on via SAINT), regeneration of affected ABAP programs via SGEN.
v) Co-ordination of regression testing: This may involve change management, regression testing and functional owner of the application / process area.
Some of the points we learnt from experience:
– Be ready to spend time in advance of the actual development in prototyping and investigation. However, it pays back in later stages of projects.
– We had to build application logging on ECC side so that in case of errors a functional person knows what to look for.
– There was one instance where we had to overwrite SAP solution. Fortunately, it can always be over-written as a post-exit method in the implementing ABAP class.
– Update some of the system parameters ( e.g. icm/keep_alive_timeout parameter in downstream PI systems). While transporting ESR contents, we realised that the transport import was failing after 5 minutes. These ESR transports with stnadard SAP content can get really big and it’s best to send them in separate transports (for each SWCV) . Our first attempt in trying to import them took 22 minutes in total!
In part2, I’ll describe the steps in more detail to make the implementation process clearer but from our experience, SOA is definitely not dead!
Link to part 2 : http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/06/04/reducing-integration-effort-by-leveraging-sap-enterprise-services-part2