Introduction
I've been working with Enterprise Services and the ES Workplace for a while now - primarily while working for the Community Project. In the case of the Community Project, we focused on the business object "Quality Issue Notification" (QIN) - a rather obscure business object - with just a few enterprise services and which ideally served our purpose in the project. When the requirements that we needed in the project didn't fit those returned by the QIN enterprise services (or others), we just changed our requirements to fit the information available.
In the real world, however, it is usually not possible to just change user requirements to fit the information returned by available enterprise services. Recently, I was asked to examine enterprise services associated with materials to assess the viability of a solution based on Enterprise SOA technology.
A Note: When we say "enterprise services", we are referring to those supplied by SAP via Enhancement Packs or partners, etc. and not those developed by the organizations that are using these services.
Individual Material vs. Material vs. Material Girl
A search look in the SDN wiki for the word "Material service" came up with promising hits, so I started looking at services that included "materials" and "individual material". I assumed they were talking about the same thing. I was pleased to see so many services that were associated with individual materials, so I started testing them to se if they would provide the information I needed. During testing with the WSNavigator, my search results always returned empty result sets and errors relating to equipment. I double-checked in the HU2 system with transaction MM03 just to prove that materials were present. Not surprisingly, I found that were more than enough materials present that should be appearing in the result sets.
Then, I saw a little table in one of the ES bundles that explained what the trouble was. There was a difference between "individual material" and "material". After reading the table, I knew that I had to distinguish between the two:
After selecting the correct business object, I now started looking at those enterprise services which I assumed would return the information required
As many business users are familiar with the data visible via the SAPGUI, they still use it as a foundation for selecting the information they wish to view in different forms. The task I was given was based on the amazing amount of data that was provided in the "Display Material" transaction (MM03) and required that a information subset be displayed in another technical environment. As might be expected, non-power-users were not expected to use the SAP GUI to access the information. If you look at the transaction in question, there is an amazing amount of information available for a single material.
I started looking for the correct services that I would need. I found the following choices:
I soon found the Enterprise Service "Read Material Basic Data" and thought it might help me. I was a little bit wary of the word "basic" which implied that there was some limitation in the amount of data returned. After checking the return structure, I was displeased - but not entirely surprised - to see that the information that I required was not available.
I checked other related enterprise services and still didn't find what I needed.
I passed on the message - which wasn't received well - that the required information wasn't currently available via enterprise services, It didn't matter if the enterprise service "Read Material Complete Data" was going to be available in Enhancement Pack 7, the user requirement already existed today and solution was necessary today.
Inasmuch as this problem may exist in a variety of other environments, I thought it might be useful to suggest a few options that are possible when faced with the similar dilemma.
Scenarios
To examine options available to deal with enterprise services that don't supply all the necessary information, it is useful to compare this scenario to one in which the services meet the requirements.
Scenario 1: Information acceptable
A BPX creating a Visual Composer component wants to access data from an ERP system - preferably via 1 or more Enterprise Services. The BPX has certain customer requirements regarding the information that shall be returned. The data provided by the existing Enterprise is acceptable and meets the requirements in question.
Option 1: Direct Access to the Enterprise Services.
In this option, the BPX assess the appropriate enterprise service via the Service Registry.
Option 2: Indirect Access to Enterprise Services via Visual Composer-based Service Components.
Those services provided by SAP's Enterprise-SOA technology often include a variety of parameters (many of them relate to technical attributes, such as language code, scheme id, etc.) that the BPX doesn't need to see in order to create his/her component. A Visual Composer developer can create Visual Composer Service Components that wrap these complicated services making the BPX's job easier.
The Visual Composer Developer can also combine multiple enterprise services into a single service that is necessary to display information.
Scenario 2: The information provided by the existing Enterprise Service(s) do not meet the application / process requirements.
Option 1: CAF Core
A CAF Core developer uses a mixture of 1-N existing enterprise services possibly combined with data from 1-N other sources (for example, BAPIs) to find all the necessary data and present it to the BPX for display in Visual Composer. The CAF Core developer then publishes the resulting web-service for use in Visual Composer.
This option is similar to Option 2 in the first scenario. Inasmuch as the development environment for CAF Core is more sophisticated and might be more appropriate for the combination of multiple data sources involving more complicated manipulation of data. Performance concerns may also necessitate the use of CAF Core instead of Visual Composer service components. If usage outside of VC is desired, then CAF Core is also preferable.
Option 2: Direct BAPI access
Most Enterprise Services have their roots in BAPIs. Obviously, there is not a 1:1 relationship between BAPIs and Enterprise Services. If this was the case, then the work of the ES Community won't be necessary.
Just because an Enterprise Service doesn't exist, doesn't mean that there isn't a BAPI that might supply the correct information. The trouble is finding the appropriate BAPI and having to deal with the necessity of having technical knowledge of BAPI structures and behavior to use the BAPI correctly.
Since Visual Composer has the ability to use BAPIs, one option would have the BPX accesses the ERP data directly via a BAPI call.
Inasmuch as not all BAPIs are currently mapped to Enterprise Services (or indeed will be mapped to Enterprise Services in the future), there may be an existing BAPI which provides the information required. If this BAPI doesn't exist, then a new BAPI must be developed.
If a new BAPI must be developed, then one possible variant with this option is similar to that of that including the CAF Core developer. The BAPI developer uses existing Enterprise Services and combines them with data from other BAPIs or directly from SAP tables to return the information desired by the BPX.
If the direct usage of BAPIs is not desired, then the BPX can access ERP data indirectly via a web-service call that in turn calls a BAPI (which could be new or previously available). This solution might be appropriate for scenarios where various applications (.Net, Visual Composer, Guided Procedure, etc.) may wish to access the data. Notice that I've distinguished between a web-service and an enterprise service...
Option 3: The long-term approach via participation in ES Community
Of course, corporations can stop complaining that the existing enterprise services don't fulfill their requirements and start actively participating in the definition of those services that are important to them. The ES Community has various work groups that are currently working on defining future services.
This is a definitely a long-term approach, because there is an obvious time-lag between the definition of theses services and their availability in Enhancement Packs.
Conclusion
A fundamental problem with SAP-based enterprise services - that they might not meet all user requirements - is not unique to ESs. The same problem existed / exists with BAPIs. To describe enterprise services and BAPIs in the same breath and in the same way is not really correct. Enterprise services include business semantics and many have been defined via industry groups:
| Business semantics: enterprise services are structured according to a harmonized enterprise model based on process components, business objects, and global data types (GDTs). They are defined using an outside-in approach: common business rules and know-how, rather than SAP-specific implementations, are the guideline for defining the business content of SAP applications |
Thus, short-term solutions primarily view enterprise services as web-services that must be enriched with additional information or replaced by other technical vehicles. Long term options are based on an understanding of the involved lifecycle / process -primarily based on the ES Community- that is at the foundation of SAP ‘s Enterprise SOA technology.
It is probably best to pursue select the appropriate short-term option to deal with the immediate business need and increase corporate participation in the ES Community to achieve long-term strategic goals.
