Skip to Content

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

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Sarat Atluri

    Nice article Vikas.

    I agree with you that the Enterprise Services have been under utilized in Integration.

    Most of the clients that I worked with, didn’t leverage the ES.

    I guess that’s mainly because of 2 reasons.

    1) Reluctance to embrace new way of doing things

    2) Couldn’t clearly see the steps involved in achieving it

    For the one client that I introduced ES, they could see the amount of complexity it reduces in design, implementation and support phases.

    Hopefully your articles will shed more light on the implementation path.

    Thanks,

    Sarat.

    (0) 
    1. Vikas Singh Post author

      Hi Sarat,

      I’ve replied in part 2’s comments about how it could be made more adopted – just some thoughts.

      In my own experience we had to spend the most effort in design . Implementation was actually easier than my previous experience. For support, I don’t see it any different than other interfaces. In fact, all previous interfaces with external systems were file based using ftp services requiring daily monitoring of ftp folders ( just in case the comm channel “hangs” becuase of locks etc. – so the support requirement actually is less of an overhead). All we needed to do was to add these interfaces in alert configuration.

      I agree that in the beginning the steps were not clear to me as well. However SAP has some good documentation around it – I’ve put the reference material which can be helpful in part 2 -. This was also the motivation for me to write the blog – hopefully it makes the process more transparent to people .

      About reluctance to embrace new way of doing things – it’s a bit philosophical but change is the only non changing entity and normally things change as someone has found a different, often better way of doing things which makes things more efficient. In the long term, we’re going to make things only better by embracing the newer way of doing things though there can be a few bumps along the way which is normal when trying out something new.

      Thanks,

      Vikas

      (0) 

Leave a Reply