Skip to Content
Author's profile photo Former Member

The COmmon Reference Architecture (CORA), Part VI

Co-bloggers: Wilco Menge, Maarten Engels


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.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.