Skip to Content
Author's profile photo Former Member

The COmmon Reference Architecture (CORA), Part V

Co-bloggers: Wilco Menge, Maarten Engels.


This blog is the fifth 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 this blog post the ROA architecture style is mapped onto the CORA model, based on a software  development project, connecting an iPhone App with SAP.

This project is based on a demo scenario and CORA  is used as a model to support architecting software. In this part the demo scenario and it’s background is  described. Also, the actual mapping of components in the demo scenario  onto the CORA model is shown. In the second part we present the  findings and lessons learned from this project. Also CORA’s benefits  and our next steps in the project are outlined.


During the last two years or so, Resource  Oriented Architecture (ROA for short) has become more and more  common as an alternative for other application styles such as n-tier and  SOA. In particular, the rise of so called “Web 2.0”  applications on the Internet contributed greatly to the popularity of  ROA as an implementation of the REST architecture, in  particular due to it’s simplicity and it’s light-weight.

We became curious: what would ROA do in an SAP environment? Could ROA  be an alternative for SOA? We already knew others were working on  communicating with SAP through REST, but we wanted to take it one step  further: we wanted to see whether we could make ROA work in a real life  application that could really provide value to users!

The demo scenario which would make us rich

After a couple of  brainstormsessions we came up with a brilliant  idea: a mobile scenario where consumers would be able to generate  recipes and shopping lists based on food allergies.

Recipes typically describe lists of ingredients as well as  instructions on preparation. Using traditional recipes for humans with  food allergies is difficult because somebody might be a might be  allergic to specific ingredients. Let’s look at an example to clarify  this.

A recipe for a rice dish requires Green Curry paste. So the recipe will  list as one of the ingredients “Green Curry paste”. Imagine someone  allergic to Dairy products. Whether this person can use this recipe is  dependent on whether Green Curry pastes exist without any dairy  ingredients. These might exist, but finding them in a supermarket can be  quite taxing. For someone with a food allergy it would be much easier  to simply have a recipe that states the use of specific products (i.e. “Asia’s  Finest Green Curry”) which do not contain the person’s allergants. Even  better would be if only recipes are generated based on allergy as well  as the stock available in a specific supermarket, as not every brand or  product is available in any supermarket.

So this was our dream: to develop an mobile App that could translate  recipe’s into lists of actual products, based on the information about  stock available in the consumers supermarket of choice.  This App should  developed for the Apple iPhone, interfacing with an SAP back-end  through REST.

Next we started designing and developing the iPhone App, the REST  interface and connection with SAP. After a while we came across many  more findings and design choices than we had imagined, so came to the  conclusion we needed an architecture reference model to help us making  the correct steps. This was the moment we introduced the CORA model in  out project, which is presented in the next section.

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.

In the next part the question mark boxes are analysed and the  findings and lessons learned from this project are descibed. Also CORA’s  benefits and our next steps in the project are outlined.

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.