The CORA Model

A practical guide on using a COmmon Reference Architecture to design
and deliver integrated IT solutions successfully
  • Home
  • CORA Model
    • CORA Requirements
    • CORA Foundation
    • CORA and Business Logic
    • CORA Layers...
      • Overview
      • Channel Access
      • Presentation
      • Composition
      • Integration
      • Application
      • Data
      • Security & Compliance
      • IT Governance
    • Target Groups
    • Sitemap
  • Connections
    • Enterprise Architecture...
      • CORA and Technovision...
        • CORA and Application Lifecycles
        • Technology Trends...
          • Overview
          • You Experience
          • We Collaborate
          • Process on the Fly
          • Thriving on Data
          • Sector-as-a-Service
      • CORA and TOGAF
      • CORA and Archimate
      • CORA and IAF
    • Sol./Softw. Architecture
    • Vendor Connection...
      • CORA and SAP
      • CORA and Oracle
      • CORA and Microsoft
      • CORA and IBM
    • Cloud Computing...
      • Overview
      • Static and Dynamic view
      • ERP and PaaS
  • Methodology
  • Experiences
  • The Authors
  • The Book
    • Paper Version
    • eBook

A ROA based iPhone App for SAP: Part I

PostAuthorIconWritten by Maarten Engels & Wilco Menge | Print | E-mail

Introduction

This blog post is the first in a serie of two describing the findings and lessons learned of applying the CORA model in a software development project. This project is based on a demo scenario where CORA is used as a model to support architecting software.

In this blog post the post 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 blog post we present the findings and lessons learned from this project. Also  CORA’s benefits and our next steps in the project are outlined.

Background

During the last two years or so, Resource Oriented Architecture (ROA for short [1]) 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.

siphone0001

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 blog post 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. This e-mail address is being protected from spambots. You need JavaScript enabled to view it is working at Capgemini as an SAP software developer and technologist extraordinaire.

Ir. This e-mail address is being protected from spambots. You need JavaScript enabled to view it is working at Capgemini as an SAP solution architect. He also leads his practice’s SAP Technology Profession Group.


[1] In this blog post we do not make a formal division between REST and ROA and will use the terms interchangeably.


 
Follow Us on Twitter

theo_elzinga1_klein     leon_klein

Latest Articles
  • Assessing IT solutions with CORA
  • CORA and Archimate
  • Architecture Styles and CORA
  • ERP and PaaS
  • CORA and Application Lifecycles
  • CORA Methodology (Project level)
  • The roadmap for Fusion Applications, CORA is there to help
  • Technovisions "Sector-as-a-Service" mapped
  • Business Logic and the CORA Model, Part II
  • CORA and Cloud Computing: Static versus Dynamic View
  • Technovisions "Thriving on Data" mapped
  • CORA Foundation
  • Business Logic and the CORA Model, Part I
  • CORA and IBM
  • CORA and Microsoft
  • CORA and Cloud Computing: Overview
  • Technovisions "Process-on-the-Fly" mapped onto CORA
  • Risk aware design: using CORA to investigate an IT solution
  • A ROA based iPhone App for SAP: Part II
  • A ROA based iPhone App for SAP: Part I
  • Technovisions "We Collaborate" mapped onto CORA
  • SAP platform decomposition with CORA: SOA/ROA style
  • 'Why' Driven Solution crafting
  • CORA and TOGAF
  • SAP platform decomposition with CORA: N-tier style
  • Requirements for CORA
  • CORA and Oracle
  • Technovisions "You Experience" mapped onto CORA
  • CORA and SAP
  • CORA in action: design guidelines to implement repositories
  • The basis of all, your data
  • CORA and IAF
  • Technovision and CORA - Overview
  • The importance of an Integration layer

Joomla template created with Artisteer.