If master data is backbone of ESA then why BDC?

[stephenjohannes]

This question is being posed here because it is more of a rant than a true technical discussion.

In trying to revisit a MDM process we created last year, I was investigating the BAPI's available for creating/changing vendors in our ERP 2004 system. Needless to say I was not impress that there were no true "background" BAPI's available. A thought was given to look at how IDOC inbound processing would work for creating/changing vendors. I took a look and was almost disgusted by what I found.

A generated BDC is still being used to load vendors via IDOC processing. The whole inbound idoc processing generates a BDC via FM VENDOR_BDCDATA and then does you typical call transaction XK01/XK02. I found this via FM ERP_IDOC_INPUT_CREDITOR after looking at however the IDOC processing was defined for CREMAS04.

My question if Master Data is the backbone, then why are BDC's still being used for a such critical piece and why can't there be BAPI's that can be used for true background processing. Is there something I am missing in looking at this problem?

Take care,

Stephen

[former_member181923]

Not gonna take sides here ... just stopping in to observe that this thread is probably one of the most meaningful threads that's going to be posted at SDN this year ... and it's posted in Coffee Corner.

This says a lot about SDN in many different ways.

djh

[Former Member]

that's the idea with the enterprise services bundles or packages. maybe you can find an enterprise service to change vendor in one of those. SAP is supposed to service enable mySAP Business suite with thousand of services to interact with whatever data exist in the applications. but if you want something now and the bapi doesn't exist or doesn't do a good job, that's too bad. maybe with a little patience and hope you'll get it from SAP. I think you can influence SAP development of those services/bapis via the Enterprise Service Communities.

[stephenjohannes]

Andre,

I actually viewed the Enterprise Services Index to see what would be available. Unfortunately there is nothing available in that index. I guess my point is that if the "core is rotten" then putting a shiny new exterior will not solve the fundamental issues that the core poses. I also think since we are talking about ECC 5.0 and above that basic core interfaces should have been fixed/provided by now. If new services does not involve "fixing" and creating API's as needed to faciliate what is needed, then we basically have an ITS-style band-aid ESA solution. Will the enterprise services be based on creating true "API" to the system, or will we just ride on top of BDC's and other cludgery and get the ESA equivalent of the ITS.

I guess after working with CRM for many years, it is amazing that the API functionality that CRM has by default did not spill back over to ERP side of the house. I also think the initial enterprise services for CRM are very weak in terms of offering. Technically almost every process in CRM should/could have been delivered as an enterprise service from the start. The XIF adapter and all the underlying API's give the solid foundation to easily build enterprise services without need to modify the system.

I'm patient, but like most people I needed the functionality yesterday and of course unwilling to upgrade to get that functionality :).

Take care,

Stephen

[thomas_jung]

>If new services does not involve "fixing" and creating API's as needed to faciliate what is needed, then we basically have an ITS-style band-aid ESA solution.

I believe that the important point you should take away here is that the Enterprise Services themselves are the new APIs. Don't expect to see massive changes/additions to the BAPIs or for SAP to heavily use BAPIs as the underlying technology of the Enterprise Services.

Let us take a look at the Create Sales Order Enterprise Service in ERP as an example. I use this an example out of convienience because I have been working with a it a lot recently. The service itself was modelled in PI, but implemented in ERP as a server proxy class. Now what is interesting is if we look inside the implementation of the server proxy. No there is no Call Transaction in there (unlike the old sales order BAPI), but at the same time - it hasn't thown away the investment SAP and its customers (through User Exits) may have made in the existing logic in the PBO/PAI of the Sales Order transaction.

The Sales Order Enterprise Service calles the function modules of function group SLS_LORD (similar to the new Web Dynpro ABAP version of Order Entry - LORD_MAINTAIN_COMP). Technically you might consider these function modules your new API - although they are not intended for public usage. They hook into the existing logic embedded in SAPMV45A, without technically passing through the dynpro screens. This ensures a single code base is executed regardless of the mechanism (VA01/LORD_MAINTAIN_COMP/Enterprise Service) to get an order into the system.

So is this a band-aid solution? I don't think so after studying the architecture of solution; it seems quite elegant - but I'm admitted biased considering who signs my paychecks. I encourage you to study it as well. To me it seems like a good way to introduce flexibility without having to start from scratch (ESOA by Evolution) yet doesn't have a "tacked-on" feel. It also allows customers to operate ESOA based processes in place side-by-side with the existing SAPGui processes.

> but like most people I needed the functionality yesterday and of course unwilling to upgrade to get that functionality

Well the yesterday part we can't necessarily help you with. It does take time to properly design and build these Enterprise Services - even when leveraging as much existing business logic as possible. If we went too fast we might end up with the band-aid approach you fear and no one wants that. But with the Enhancement Packages for ERP, we do have a mechanism (and schedule) to delivery new services approx. twice a year - in a technical manner that does not require you to upgrade your system.

[stephenjohannes]

Thomas,

Actually that is what I was expecting when the new Enterprise Services are delivered. It is good to see that a "clean API" is being built and not re-use of existing external API's which the results may vary by application. I am sometimes skeptical on whether what will be delivered is what will be needed.

My biggest technical hurdle has been on projects is that the SAP API for the business process has not been exposed fully enough in order to replicate that process. The full exposure means, that anything that can be manually entered by an end-user in transaction screen delivered by SAP, should be available for entry by external means. Too many of the old BAPI's etc, couldn't meet this basic requirement on the older releases. This became a pain even on projects where I was using SAP software to create "custom views" on existing processes. E-commerce apps were also a pain because of this.

The "MDM process" that I am looking at the desing currently uses a BDC, which is causing the issues of adding/changing fields is requiring too much rework in the ABAP code. A real API would solve of this pain and allow us to start re-build this in an ESA-lite fashion without waiting for us to upgrade to ERP 2005. I wish that this issue was our only pain-point in the process/application redesign.

Once we get to ERP2005, then I am sure the pain levels will be reduced somewhat and the delivery of new services will allow us to take advantage of using more building block approaches. Unfortuantely to borrow term from racing, the restricter plate is on our vehicle. Thank you though for the response and insight.

Take care,

Stephen

[Former Member]

I think with your knowledge it'd be cheaper for your company to go the old way rather than the new way. There's nothing wrong with BDC if that's your only immediate option. You cannot have/talk ESA or enterprise SOA without being on ECC5 or 6. Upgrading to ECC5 is by itself a whole different story and there's no guarantee you'll get the bapi or service you need.

So bottom line is don't worry you're not alone. I'm with you on this and i think SAP itself and its whole ecosystem. But there's a good part in this story: it provide jobs to armies of consultants and developers

[stephenjohannes]

As a followup if anyone is keeping score of the situation, I believe there is finally an Enterprise Service available in ERP Ehp4 that will deal with creation of supplier(vendor) master data.

I'm going to be very very interested to see if they took the route of building the interface completely from scratch.

If anyone knows more about how the SupplierERPCreateRequest_In is built in ERP Ehp4, details would be appreciated.

http://esoadocu.sap.com/socoview(bD1lbiZjPTAwMSZkPW1pbg==)/render.asp?packageid=DBBB6D8AA3B382F191E0...

Take care,

Stephen