....Continued from "The Architect's World - Episode 45 Part 1". 
Plan the customized components you plan to build, if any, if you wish to use the same in your other composites to follow. Release the same to a pilot set of users, set things right and go-live with a back-up plan.Calculate the ROI at regular time intervals for a couple of quarters and you would be sitting on a goldmine idea to retire applications from a landscape infested with non-SAP applications that you found out in your A,B,C classification of applications that now need your attention for retiral. Again, the above steps are inly indicative and based on expetrience. There could be many other ways in which you could plan your things better. What has not been discussed is the servcer side implementation of the service composition layer of Application and entity services, but that is a topic in itself and best left to the appliction development team. So, unlike building composites that may end up serving a miniscule set of users, a reverse-engineered composite application certainly has the potential of going a long way in changing the way best-of breed, 3rd party, custom or legacy applications help as support systems today with the "side-car" approach.
Step 10: Plan the design for the xApp:
A key step in planning your composite application is to try to see how to fit the architecture of CAF on top of the paper application that you built. If you see the image below (a standard representation of CAF Architecture), it represents the technical architecture of a CAF application in terms of layers, which is a best practice of architecture addressing the implicit requirements of any application - namely, your composite application. If you break this layer down into 2 parts, one, as the backend layer and the two, as the service composition layer above it.
So, the back end implementations of your enterprise are to/presumed to be service enabled and brought up as the service enablement layer which can comprise of any service be it a BAPI or a Web service and it could be even an API interface. Relate the same in the context of the ESR and you have a winner here. Improve the ability of business packages that get defined in terms of roles that access the ESR via PI and provide a business benefit is an added benefit that you can build on top of this layer.
In the composition layer, the bottom most layer is the Entity service layer (a part of the business objects tier) which serves as the value object for communicating back and forth the services layer, manipulated and consumed by another layer above this, the Application Services layer, where you can put in your custom code for additional logic building. Better aspect, if you are not satisfied by this mash-up alone, convert this into web-services, publish them into your UDDI server and call them up through your GP layer - in a way definining a linear architecture for future composites to come up within your landscape.
The Application services layer covers the entities beneath it and also can directly contact the services layer if required based on the design requirement of your composite that you plan to build. The Application services take care of the business logic and the workflow part of the application. Together, the entity services and Application services form the Core Services in a CAF architecture. The GP layer consisits of the Callable objects, Actions, Blocks and the Process. So, the work of identifying and segregating your business objects logically to provide a business meaning becomes extremely critical here.
Since, the UI part of the application is conceived as a callable object (increasing with every SPS release) and it maps one on one to an Action in CAF. The callable object represents the technical side and Action gives a business sense to the callable object and so the way you design the objects now start making business sense. The actions are orchestrated by a Block in a sequesce based on the workflow requirements – it could be sequential or parallel as dictated by your application needs . A collection of blocks represent a process and will be in turn triggered by a role logging into the composite application and this activity directly maps on to the step where you defined your roles vrs your process as the "X-Y process mapping". Choose how you want to play the above.
Step 11: Create the Architectural design for the xApp:
In this step, you define the superimposition of your composite's acrhitecture on top of the CAF architecture. in the case of R/3 4.6 c and MDM 5.5 are the back end implementations. RFC’s and MDM API’s are the services that are available in the service enablement layer. Of course, the backend implementation could have been a higher version (which would only be better, saving one the job of creating the application and entity services and publishing them into a UDDI registry. And that's a cool objective of an upgrade to an ECC 6.0 version.
The next step while designing your composite is to test out the end-to-end process flow through the composite as a POC, a move that will only help you revisit and finalize the architecture that you choose to use. Sample process flow in iPRO-to create a Catalog Item Request: When the Requestor logs in and triggers the Create Requisition process, it is instantiated and displays the first action of the block as a form. In our example the User Details action is a back ground callable object execution and the form loaded is the Add title Action. Once the user keys in the details and submits then the next Action is displayed in sequence. Once the block is completed for the last Action and the user summits then the Requisition Application Service is triggered and inturn triggers the Account, the Item and PurchaseRequisition Entity services. These Entity services are mapped to the corresponding R/3 BAPI’s and will transfer the values via the BAPI’s to create the Requisition in the R/3. The result of the creation is then displayed as a response in a callable object which will complete the process. If you take this approach as an example and try to map the logic of the same while defining the objects within your composite, it certainly would make your life a whole lot easier.
Step 12: Plan the way in which Objects to be created/Orchestrated:
The design time of the composite application requires the NWDS, VC and the GP Design development activities Or the SAP NetWeaver Composition platform. These steps cover the activities to be carried out to develop a GP process. First step addresses the developemnt of UI and the Core service of the composite. The Core services of the CAF layer is developed in the NWDS and the GP objects in the GP design time. Apart from the Core services the Web Dynpro Development Components which are the UI screens are also developed in NWDS and the necessary codes to make it eligible for the Callable objects creation is done in Web Dynpro implementations. These Core service objects and the Web Dynpro DC’s are then deployed on to the WAS. One thing that was a big learning as part of the iPRO build was the logical segregation of objects - which are the activites that one defines as an action? Which ones are a block? A process? What maps one to one? What is the naming convention? How does one modularize the development? Again, the useage of VC did not feature as this was built on SPS 7, the plan is now two-fold. Move a few UIs to VC and use WD4VC Callable objects, move away from a few BAPIs and call them straight through as web services through the GP layer. More or less, define more and more of composition for the application. A critical architectural decision when you contemplate building your own.
Since the idea now is not to focus on the implementation side of the core services, but to see how the process can be built, this image is shown as a representative one for the previously discussed activities of the NWDS. This screen shot shows how External services can be imported into the NWDS composite project. The parameters of the BAPI’s are mapped to the attributes of an Entity Service and the Entity services can be manipulated by an Application Service. When deployed to WAS, this Composite Application Service can be created as a CASCO in the GP Design time. Of course, it is purely an architectural design whether you want to import these objects here and manipulate them in your Application service with custom code, or would you rather use them as is and call them straight in the GP layer as your enterprise services may anyways be doing the manipulation well as-is? This way, you could choose to do awy with the redundant layering of wrapping up services and calling them as Composite Application Service Callable objects, when you could call them straight from the GP layer with SPS8. Again, a point of consideration for your architectural decisions when you embark on a build.
Step 13: Plan the Objects to be created:
Here is where you plan the orchestration and the useage of the GP layer vis-a-vis your CAF core layer. The next step (flowing from the previous one), is to import BAPIs that will help you create callable objects of type “Composite Application CO”. If you were to create an external service callable object, it could directly be done from the GP design time where you configure your endpoint alias and select the service. So, which is the way you plan to build your composite? The decisions get tougher with the planning of Many ready made templates based on the type of Callable object are available in SPS7. In SPS8, there are three additional Callable objects Web Service, business logic and WD4VC (Web Dynpro for Visual Composer) are added - a far cry from previous SPS and certainly with every release the composition platform just gets better. The ultimate move is the orchestration of complex enterprise services with the newer release.
Step 13: Plan the Callable Objects to be used:
Any object that can be called through the composition layer - shouldn't one call it a callable object? For example, The Web service callable object type which was not possible in the previous SPs is a very useful callable object which will enable any published web service to be made use of in the composite application. Till SPS7, if one had to use a Web service then the same had to wrapped in an Application Service, converted as a Callable object and used in a composite. This becomes a tough call. In iPRO Background CO, CASCO, External Service CO, Web Dynpro component CO and Notification type CO’s are used. A Callable Object could be an object which represents the service functionality of an underlying implementation. This is probably the most difficult part of identifying the objects for useage. With every release, the list of callable objects seems to only grow longer making the choices only tougher. Plan it well, take the most stable and tested ones for your application.
Define the naming conventions which reflect the functionality the callable object does and the Actions are given the same name as the Callable objects so that there is a on to one correspondence. In iPRO there are 183 Callable objects and as many Actions. In continuation to the previous image, this one shows how a Callable object is attached to an Action. As you see in GP Design time, the Create Purchase order callable object is attached to the Action CreatePurchaseorder. Also note the same name is given for both the Action and the callable object. The next step is to create the Block and attach the previously created Actions.
Step 14: Plan the Orchestration with the Blocks/Processes to be created/used:
Figure out what goes into your blocks. Consider it a static workflow executable that executes the Actions in a particular sequence. With the different types of Blocks available viz, sequential, parallel, conditional etc, you need to choose what best meets your process requirements to rever-engineer your application.
In iPRO, to create a Catalog Item Request, as the Requestor logs in and the process initiated this block is loaded and the Action Initial Catalog BG is triggered as the first Action.BG refrs to back ground Callable object type. The next action fetches the Requestor details which inturn uses the Back Ground CO CASUserDetailsBG. The UI screens Addtitle, Additems, Add Accounting, Add Shipping, Addcomments, Summary are loaded in sequence within the block.In between different helper calable objects in terms of back ground callable object and CASCO for fetching the GL Account details, master Data like Plant, Purchase organization, Purchase Group etc are fetched to be used for futher processing.These data are stored in the Callable object Structure which are mapped in/out of the successive Callable objects. Finally the collected values of the structure are then passed to the Entity service via an Aplication service which are maped to the RFC parameters of the BAPI and finally pushes the data to R/3.
The response from R/3 is then displayed to the Requestor as an Action/Callable object with the PR no.based on the docType of the item requested to differentiate b/w Catalog and Non-catalog items. Next step is to create the Processes and attach the Blocks earlier created to them. These are the different processes created for iPRO. There are 11 processes used. If you notice the Processes, there are grouped by the Functionality. During the design phase it is best practice to draw the sequence diagrams based on the Functionality which will help in identifying the Processes, blocks and the Actions. Once a Block is attached to the process ,all the associated Actions/Callable Objects of the Block also get attached in the same sequence. This approach helps you define the entire orchestration of the process within the composition framework that could be the POC extended for a full-blown application and have it called through the Portal as follows, post instantiation.
Steps 16....20...Outro: Plan the Road Ahead as an ESA Architect:
Plan the customized components you plan to build, if any, if you wish to use the same in your other composites to follow. Release the same to a pilot set of users, set things right and go-live with a back-up plan.Calculate the ROI at regular time intervals for a couple of quarters and you would be sitting on a goldmine idea to retire applications from a landscape infested with non-SAP applications that you found out in your A,B,C classification of applications that now need your attention for retiral. Again, the above steps are inly indicative and based on expetrience. There could be many other ways in which you could plan your things better. What has not been discussed is the servcer side implementation of the service composition layer of Application and entity services, but that is a topic in itself and best left to the appliction development team. So, unlike building composites that may end up serving a miniscule set of users, a reverse-engineered composite application certainly has the potential of going a long way in changing the way best-of breed, 3rd party, custom or legacy applications help as support systems today with the "side-car" approach.
