Skip to Content

The traditional ERP defined value chains in various organizations are getting modularized to cater to the needs of processes which were hitherto undefined, yet the same needs to be addressed in a systemic way. What leads to reorganization of value chains within this network evolution, flexibility and adaptive business processes have become key that demand immediate attention. This is an area that needs focus for organizations willing to adopt ESA. A focus area that now should change the very operative models of System Integrators. Having taken the portfolio of applications from a system landscape that could be molded into process chains on the SAP NetWeaver platform to ensure driving innovative and volatile applications to adapt more quickly to changing business needs. The reusability of services to be orchestration and re-orchestration at a process level that can be efficiently composed by a business expert in conjunction with developers would slowly render the need for an ESA landscape for any organization that is planning out an IT strategy for the next few years. More and more composites will soon be evolving (reminding one of the B2B reminiscence with mushrooming marketplaces) with the composite application framework.

Composite applications focus on user-centricity. It is this factor that enables collaborative and dynamic processes to be adapted quickly to ensure to comply with regulations, to adapt to new processes, to bring forth a rich-user experience, and, most importantly, reusability. The starting point for the composite applications as follows:

Ensuring semantic integration:

Not just merely viewing, to ensure that one integrates the applications with a common language across existing applications within a system landscape to build adaptive processes on the fly is what is being asked for by the organizations. This is not white-paper talk, but rather, a direct communication that I get to hear from the CXO levels of any organization wherever I have had to conduct an ESA Workshop. This is not to be mistaken with a pretty-faced integrated reporting with dashboards and speedometers (a fact that many within SAP AG themselves have to comprehend), but the enabling of services across multiple systems – SAP and non-SAP, to ensure this integration with XI, if necessary. Integrating information from backend systems calls for a consistent language/business object model for the composite. Objects specific to a process being addressed in the composite per the definitions that are relevant for the xApps itself – has to create its own business object layer defined within itself. The BPX having defined the process that needs support will now leverage the service enabled systems within the SLD (and external services) to create an application that would cover the process end-to-end, not just the SAP systems in the landscape. The defined business objects would remain as independent entities within the composite itself that is fed from the backend, a subset of the data that exists leading to semantic integration. Now, with this, the application logic can be built to shield the composite layer from the application logic. Once the services are exposed in the User interface that the BPX can work with actions and deal with the business process. A step in a business process can go through the semantic layer of the composite application and some steps might just be calling objects directly from the backend applications that need no further processing and can be brought straight up.

Customization can never be done away with:

However noble the thoughts around xApps may be, to render an application truly useful within an organizational context, one can never rule out the need for customizations. Consider our application conceptualized on SDN, built on CAF 7.0 – iPRO:

Portal DB Design: The application related data is stored in the Portal DB. We had to create additional tables to ensure the enhancement of user data to render the xApp an effective one in terms of workflow, so that one does away with the need of ABAP workflow in this context. (Of course, the bigger picture now becomes – how do we create a strong workflow center within CAF that can be leveraged by multiple composites to ensure reusability among applications that more of less demand similar processing capabilities in terms of approvals?):

The following tables are required for iPRO to ensure that we create a dollar-limit based workflow trigger mechanism that can be easily administered with custom web-dynpros. Shall we say that this is a move towards enhancing the capabilities of CAF 7.0?:

– User profile to store user info that is relevant for iPRO, without having AD or SAP be the source of truth for all data

– A purchase Request transaction table to store the Purchase requests info raised by the user.

– Request Status table to store the status code master info for easier tracking of the Purchase requisitions within iPRO itself

– Approval Rule table for the set of approval rules for the catalog and non-catalog items to bring out process requirements based on suppliers, commodity codes etc.

– Items table to store info about the items of the PR till the time it is saved and is not yet submitted

– A condition parameter table to store info on the parameters about the conditions checked in the approval rule that is needed for the processing of complex rules within iPRO

– A condition set table to hold the mappings with the condition parameters to a set for which the rule is validated so that the correct pre-defined rule is picked up

– User group table to hold the group info of the users to help bucket these groups into roles that can then be scaled up for analytics with cool dashboards or just plain grouping of iViews per function

– Approval flow table to decide on the users participating in the approval based on the approval rule to address specific business rules within the application itself

What can this mean for other xApps?

Plain and simple – not every customization as listed above will find relevance in a particular business scenario. But, the nature of the application that an organization would call an xApp will dictate the level of customization that will be needed to make it a useful application. Consider a PBNW application that gets built into a composite, or a plain re-orchestration of services to build a composite or a combination of the above extended to address a larger process chain, each one will demand a set of customization that will be core to its business. Or, shall one term this as configuration activities that one would define for an xApp?

R/3 SPRO settings that may be needed:

In a lab, one predominantly tends to hack away and work in IDES clients and loses out on a lot of pre-setting that a BPX would anyways know. In the case of iPRO, the following settings can be looked at to make sure it works in a live environment :

For the identified Company Code, the plan and the Purchasing organization, create new PR types. Now, why on earth would you do that? The answer is fairly straight forward: Once a PR (same case with PO) is to be pushed from the xApp level to R/3, one would definitely want to see as to how to segregate PR/POs created as ad-hoc items or pushed in as catalog purchases. The easiest way to do it would be to use different PR/PO types (maybe invoices as well) and different number ranges for the documents pushed out from iPRO. But the fact remains that such activities would need to be done if an approach to an xApp is as complicated as one with iPRO. Range “5000000000 – 5099999999” for the iPRO PRs, “ZPRC” PO Type for catalog items and “ZPRO” PO Type for Ad-hoc requisitions with their respective PO types attached to them. Zero in on the account category and the item categories that you many want attached to the PO doc types along with the account assignment categories that would be mapped with the help of the BPX.

OBYC valuation and Account assignments need to be checked, G/L account assignments. Check. Invoice verification code, tax Jurisdiction codes. Check. Setting in Configuration to make Cost Center Mandatory in the Purchasing Cycle transactions via SPRO-> Materials Management -> Purchasing -> A\c Assignment -> Maintain Account Assignment Category -> Select Cost Center -> Mark Cost Center as Mandatory to ensure that the cost center details are always captured in iPRO. Other such settings that will need to take place to run the R/3 cycle smooth. Bottom line – for any xApp that would be knit together from a composite perspective, it is mandatory to see the cycle functioning within the R/3 or ECC environment. Else, we are talking esoteric with CAF.

Work it on paper first:

Service Composition and orchestration is the key aspect of any xApp, if it is to leverage existing data and information along with the user experience and the flexibility for the process definition to bring about efficiencies. SAP CAF is ultimately a methodology and toolset to build and manage Composite Applications that make business sense, leveraging SAP NetWeaver capabilities. So, it has to tie up into the SLD, needs to be planned as part of the ESA roadmap. The process layer of Guided procedures should be an extension of all the quality aspects of process definitions within an organization, which gets translated by the creation and execution of cross component workflows (wherever) with Guided Procedures and the use of WebDynpro patterns and freestyle components, as well as Interactive Forms wherever such a composition makes sense.

Import of external services like RFCs or Web Services at design or configuration time to address sub-processes that will support traditional processes with the generation of proxies for external services (java or ABAP proxies) and mapping of external services to entity and application services and composition of application services using entity and external services. The question that comes first to mind is – with so much abstraction, doesn’t it kill the performance of the application? Now that is a matter of prudence you would have to take while designing the application itself. Our experience with iPRO, however, was something that really makes one place faith in the capabilities of CAF 7.0 SP “higher”.

Note the list of BAPIs that were used in iPRO. Below is a list of BAPIs that were used for the “Catalog Item Ordering process”. Point to be noted here is, there were called in as external services, either as direct callable objects, or with the help of entity service mapping or were called in by application services. Mostly standard BAPIs, except a couple of custom ones. But this flexibility in design is exactly what the doctor ordered for any ESA Architect.

1. BAPI_REQUISITION_CREATE, Standard, called by Entity Service mapping

2. BAPI_REQUISITION_GETDETAIL, Standard, called by Entity Service mapping

3. BAPI_REQUISITION_CHANGE, Standard, called as a direct CO

4. BAPI_REQUISITION_DELETE, Standard, called by an Application Service

5. ZBAPI_PREQ_GET, Custom, called by an Application Service

6. BAPI_CONTROLLINGAREA_FIND, Standard, called by an Application Service

7. BAPI_GL_ACC_GETLIST, Standard, called by an Application Service

8. BAPI_COSTCENTER_GETLIST, Standard, called by an Application Service

9. BAPI_PO_CREATE1, Standard, called by Entity Service mapping

10. ZBAPI_PO_GET, Custom, called by an Application Service

11. Z_PURCHASE_GROUP Custom, called by an Application Service

Moral of the story – do not start and stop at CAF. Run the cycle with the ECC core as well. Else, you are sitting on a dead duck.

A useful xApp build will take time:

The Callable Objects were divided into four categories for iPRO:

1. Web Dynpro Callable Object to make way for custom webdynpros from a user-centricity perspective, giving it a similar look and feel of Ariba Buyer Useage. Same approach can be used with other xApps – lower TCO?

2. Background Callable Objects

3. Composite Application Service Callable Object

4. Notification Callable Object to trigger off mails per the process cycle need

The callable objects directly interact with the underlying CAF-Core services and are wrapped into Action objects. Web Dynpro Development Components are coded to make CO ready and deployed on to the WAS. Callable objects are created out of the deployed DC’s focussed on modular development. The elapsed time for the build? 4 months.

Conclusion:

Customizations find a new meaning with composites. It will take time to address and build the right process. The build will depend upon the nature of composite that you plan to build. It could be Ultra-light, light, medium or heavy-weight. CAF 7.0’s dependability will continue to rise with the next SP/release. Plan your ESA Adoption roadmap with CAF as the centerpiece. It is an accelerated roadmap to ESA. Worth a few bumps on the road.

To report this post you need to login first.

1 Comment

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

  1. Pankaj Kumar
    Kartik

    As always good info from the folks who have done it. Just a minor thing ESA as a term has been re-termed as 😀 as E-SOA.

    -Pankaj

    (0) 

Leave a Reply