Co-bloggers: Wilco Menge, Maarten Engels
Introduction
This blog is the sixth in a series around the usage of the CORA model in a SAP-centric environment. In the The COmmon Reference Architecture (CORA), Part I blog post, the CORA model has been introduced. In the The COmmon Reference Architecture (CORA), Part II blog post the SAP SOA Reference Architecture has been mapped onto the CORA model. In the The Common Reference Architecture (CORA), Part III blog post the 'SAP Business Suite' has been assessed by plotting the different SAP-components onto the CORA layers and elements ('SAP platform decomposition'). In the The COmmon Reference Architecture (CORA), Part IV blog post a SAP platform decomposition has been performed using a combination of the N-tier and SOA architecture style. In the fifth blog post the ROA architecture style is mapped onto the CORA model, based on a software development project, connecting an iPhone App with SAP. In this blog post the findings and lessons learned from this project, the CORA’s benefits and our next steps in the project are outlined.
Mapping our scenario to CORA
The following picture shows the mapping of our ROA application onto the CORA model.
The App is the core of our scenario, as it is the part our end-user sees and interacts with. The App will run on the Apple iPhone device and utilizes the Apple Cocoa Touch and Apple Core Data frameworks for its UI and Data layer. The only data that is stored on the device is a user profile containing allergy information for that particular user: the user can tell the App what substances or products he is allergic to.
All other information is available through the REST protocol. The App communicates with two separate resources: a system delivering recipes and allergy information and a SAP CRM system that supplies information on products and stocks. In comparison to the user allergy profile (which is very suitable to store on the users device) the amount of these types of data is usually large and will change more often. They are therefore stored as server based resources.
The Question mark boxes show problem areas or areas that needed more investigation. Some important ones are:
- The Netweaver stack does not directly support the use of REST-style webservices. It is however possible to use Netweaver BSP pages to recreate a working REST protocol. Not all HTTP operations are available, so it is not possible to build a full fledged REST Service. For our initial scenario, this was not a big problem.
- Because of data correctness, compliancy will be an issue regarding the allergy information stored along with products. In a real-life scenario, it will be a huge challenge to manage a large list of products from a large number of vendors and keep this allergy information up-to-date and correct.
Findings and lessons learned
After we performed the mapping we discovered some new things about our scenario we hadn’t noticed before creating the CORA mapping:
- Creating iPhone Apps is really about creating small monolithic applications. As they tend to be built around a single use case or set of highly related use cases they usually solve a small problem and use a very specific set of resources to do that. This means that the assets created are mostly non-reusable.
- There is nothing SOA about this scenario, even though we employed SAP technology. Everything revolves around a rich-client using point-to-point connections. This makes the app simple to implement but less easy to govern, as the connections will only be visible in the App itself.
- The most concerning issue was the notion that this scenario was nearly impossible to implement! Because of the earlier mentioned problems with data correctness it will probably be too expensive or even impossible for a supermarket to manage a real life list of more than 20K products and allergens from a large number of different vendors.
Benefits from the CORA model
It was because of performing the mapping to the CORA model that we realized we wouldn’t get rich. Besides this it provided us with great insight and it was therefore a great benefit to use this model. In more general terms, the advantages are:
- when using the CORA model you will find ‘blind spots’ in designs that are actually very important to solve (lest they become bigger issues later);
- it is easy to identify points that require additional attention, even if a complete solution is not known yet;
- by it’s simple and graphical nature it’s a great means to facilitate lively discussions on design choices and architecture styles.
Next steps
Our first next step is to finalize to a 1.0 version of the App, even though probably it can never be released for commercial purposes for the reasons outlined in the Findings section. We want to do this because the App will still be very useful as a demo instrument, showing possibilities and illustrating our lessons learned. And besides, we still think the idea is brilliant and deserves to be developed!
For the 2.0 version an interesting decision pops up. With the intention to obtain the recipes from a generic service (i.e. as a resource) we need to decide where to do the translation from the ingredients stated in the recipe into actual products. We can do this in SAP or in the iPhone or possibly entirely somewhere else.
The CORA model actually does not provide direct guidelines on where to implement business logic: it describes where it can exist, but does not explicitly state where it should be placed. It would actually be a great addition to CORA if it would also help guide functional decisions. Perhaps in CORA 2.0?
About the authors
Ir. Wilco Menge is working at Capgemini as an SAP software developer and technologist extraordinaire.
Ir. Maarten Engels is working at Capgemini as an SAP solution architect. He also leads his practice’s SAP Technology Profession Group.
