Support for parents of children with cancer

Christmas is just 2 days away and we see that another year went by faster than expected.

We had some exciting new projects in 2014 – a SQL Anywhere/MobiLink implementation on iPad/Android/Windows, SRM based on UI5, Travel Management on iPads and many more. Over all it was a good year!

It is time to realize how fortunate we are – enough food, health and a fulfilling job. After a successful year we want to give something back to those who are not as lucky as we are. This year we donated 5 000 Euro to LICHTBLICKE, an initiative to support parents of children with cancer. It is located in Augsburg, where are headquarter is.


This nonprofit organization was started in 1985. It helps parents to stay close by their children while they are in the hospital. For this reason they build a house close to the clinic. We think that this is money well spent!


We wish all our customers, partners and friends a merry Christmas and all the best for 2015!

An Introduction to OData

For allowing web applications or mobile devices to access the SAP ERP system, SAP has introduced the NetWeaver Gateway, with oData as its data format and communication protocol. In many scenarios, OData will replace classical web services or RFC communication. This blog post should give you an overview about OData, as it is central for SAP’s future strategy and used in Gateway, UI5 and HANA.

1. History

The OData protocol was created on top of the Atom Syndication Format and the Atom Publishing Format and it is using XML and http/https for communi-cation. When working with NetWeaver Gateway and UI5, an extension to the OData protocol is used called “OData for SAP”. OData is a stateless REST protocol. It can be compared to ODBC and be seen as a way to access a data-source, however it is not limited to databases.

1.1  Atom

The Atom Syndication Format was introduced in 2005 and allows to describe the content of a website in XML format. It is mainly used by news aggregators like Feedly ( or the late Google Reader to bring the content and the updates of multiple websites into a single user interface. The Atom Syndication Format is read only. The following shows an example of an Atom Syndication Format document:

<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="">

<title>UI5 Development</title>

<subtitle>Introduction to SAP UI5</subtitle>

<link href="" rel="self" />

<link href="" />




<title>Introduction to OData</title>

<link href="" />

<link rel="alternate" type="text/html"  href=""/>

<link rel="edit" href=""/>



<summary>This chapter gives an overview about the OData protocol.</summary>


<name>Alexander Ilg</name>





In the Atom Syndication Format, a collection of referenced documents is called a Feed. The single reference to a document is called on Entry. Atom Syndication Format documents are usually linked from websites:

<link href="atom.xml" type="application/atom+xml" rel="alternate" title="UI5 ATOM Feed">

1.2 OData

OData is the short form for Open Data Protocol. Microsoft introduced it in 2010. While the Atom Publishing Format allows to reference documents, it does not specify how to include additional data within a feed. OData is an extension to Atom and defines convents for specifying structured data.

OData provides definitions for:

  • Simple Types
  • Complex Types
  • Associations between entries
  • Navigation Paths between entries
  • Custom behaviour beyond the standard create, read, update and delete ( in short called CRUD) operations

1.3 OData for SAP

SAP extended the OData format to allow the data within a document to be linked to its data types in the ABAP Data Dictionary. OData for SAP was first used by SAP for Duet Enterprise.

2 OData for SAP Overview

2.1 Supported Output Formats

OData supports two different output formats:

  • Atom XML
  • JSON (Java Script Object Notation)

An example for the Atom format can be found in 1.1. The following shows an OData document in JSON:


"d" : {

"results": {

"__metadata": {

"type": "DataServiceProviderDemo.Address"


"Street": "One Sybase Drive",

"City": "Dublin",

"State": "CA",

"ZipCode": "94568",

"Country": "USA"




The benefit of JSON is the small footprint of the message and that it is easier to consume by mobile devices. As the parsing of JSON is a core part of JavaS-cript, it can be used within UI5 without much effort. For more about JSON, please refer to chapter 2.7. NetWeaver Gateway supports the JSON format since SP04.

2.2 OData Service Documents

Simple OData services can consist of just a feed, but more complex scenarios can have several feeds. In that case it can be useful to expose a service docu-ment that lists all the top-level feeds so that clients can discover these feeds. The service document contains metadata, which describes the feeds available and that links to the address of each feed that is exposed. Another way of think-ing about the service document is to see it as the data model description of a OData service.

The service document is available via an URL like

Example of an OData Service Document

The following shows an example of an OData Service Document:

<service xmlns="" xmlns:atom="" xml:base="">



<collection href="Products">



<collection href="Advertisements">



<collection href="Categories">



<collection href="Suppliers">





General Structure of a Service Document

As seen above, the service document consists of the following elements:

  •  <service> – The service tag defines the particular OData service. This is the root tag of the document and the starting point for the service consumption. It contains the xml:base attribute, which defines the URL under which the server-side reources can be accessed.
  •  <workspace> – The workspace tag contains a list of all server-side resources that are available.
  •  <title> – The title tag contains the name of the OData service
  •  <collection> – The collection tag can be present multiple times within the workspace tag. It identifies an individual server-side resource. The collection tag has the href attribute – it is important to generate the URL for this collection.
  •  <title> – The title tag within the collection element defines the name of this collection.

2.3 OData Collections

Construct a URL for a collection

Each collection can be accessed via a unique URL. The URL can be created with information from the service document:

<service xml:base> + <collection href>

If we want to access for example the products from the example in 2.2, we need to call the following URL:

If we call this URL, the server will deliver the content of the products collection.


The following is an example of a collection, in this case the products from example 2.2:


<feed xmlns="" xmlns:d=""xmlns:georss="" xmlns:gml=""xmlns:m="" xml:base="">


<title type="text">Products</title>


<link rel="self" title="Products" href="Products"/>


<id> </id>

<category term="ODataDemo.Product" scheme=""/>

<link rel="edit" title="Product" href="Products(0)"/>

<link rel="" type="application/atom+xml;type=entry"title="Category" href="Products(0)/Category"/>

<link rel="" type="application/atom+xml;type=entry"title="Supplier" href="Products(0)/Supplier"/>

<title type="text">Bread</title>

<summary type="text">Whole grain bread</summary>





<link rel="" type="application/xml" title="Category"href="Products(0)/$links/Category"/>

<link rel="" type="application/xml" title="Supplier"href="Products(0)/$links/Supplier"/>

<content type="application/xml">


<d:ID m:type="Edm.Int32">0</d:ID>

<d:ReleaseDate m:type="Edm.DateTime">1992-01-01T00:00:00</d:ReleaseDate>

<d:DiscontinuedDate m:null="true"/>

<d:Rating m:type="Edm.Int32">4</d:Rating>

<d:Price m:type="Edm.Decimal">2.5</d:Price>







<category term="ODataDemo.Product" scheme=""/>

<link rel="edit" title="Product" href="Products(1)"/>

<link rel="" type="application/atom+xml;type=entry"title="Category" href="Products(1)/Category"/>

<link rel="" type="application/atom+xml;type=entry"title="Supplier" href="Products(1)/Supplier"/>

<title type="text">Milk</title>

<summary type="text">Low fat milk</summary>





<link rel="" type="application/xml" title="Category"href="Products(1)/$links/Category"/>

<link rel="" type="application/xml" title="Supplier"href="Products(1)/$links/Supplier"/>

<content type="application/xml">


<d:ID m:type="Edm.Int32">1</d:ID>

<d:ReleaseDate m:type="Edm.DateTime">1995-10-01T00:00:00</d:ReleaseDate>

<d:DiscontinuedDate m:null="true"/>

<d:Rating m:type="Edm.Int32">3</d:Rating>

<d:Price m:type="Edm.Decimal">3.5</d:Price>




The example shows the following elements:

  •  <feed> – The feed element defines a collection of zero or more elements.
  • <entry> – The entry tag contains a single business object.
  •  <content> – The content tag contains the actual business data.
  • <properties> – Within the content tag, this is the place where all the business data goes.
  • <link> – The link tags point to related business data. In our example above we can see links to categories and suppliers.

Comparing the OData collection to the ABAP world, we get the following picture:

  • The <feed> is like a database table in ABAP
  • An <entry> can be compared to a row in an ABAP table
  • <properties> correspond to a field or column in a table.

2.4 OData generated by NetWeaver Gateway

The XML produced by NetWeaver Gateway is different to what we saw so far. SAP added the atom namespace to the first and second level tags to avoid potential namespace collisions.

The following is an excerpt from an OData collection generated by the Gateway:



<atom:link href="Flights" rel="self" type="application/atom+xml;type=feed" title="Flights"/>




<atom:category term="FlightInformation.Flight”



<atom:content type="application/xml">




<d:FlightDate m:Type="Edm.DateTime">2011-01-05T00:00:00</d:FlightDate>

<d:Price m:Type="Edm.Decimal">889.00</d:Price>


<d:Distance m:Type="Edm.Decimal">2574.0000</d:Distance>







2.5 OData Metadata
The metadata of a service document describes the data model (i.e. structure and organization of all the resources) exposed as HTTP endpoints by the service. Metadata describes its data in EDM (Entity Data Model) terms using an XML language for describing models called the Conceptual Schema Definition Language (CSDL).

The metadata can be used by developers or software to understand the datamodel of an OData service. UI5 is reading the metadata as well.
To access the metadata, the appendix $metadata has to be added to the URL. So far example, if you want the metadata for the service document, you need to call$metadata.


The following is an example of a metadata XML file:

<edmx:Edmx Version="1.0">

<edmx:DataServices m:DataServiceVersion="1.0">

<Schema Namespace="Netflix.Catalog.v2">

<EntityType Name="Genre">


<PropertyRef Name="Name"/>


<Property Name="Name" Type="Edm.String" Nullable="false" MaxLength="128" Unicode="true” FixedLength="false" m:FC_TargetPath="SyndicationTitle" m:FC_ContentKind="text" m:FC_KeepInContent="True"/>

<NavigationProperty Name="Titles" Relationship="Netflix.Catalog.v2.Genre_Titles” FromRole="Genre_Titles_Source" ToRole="Genre_Titles_Target"/>


<EntityType Name="Title" m:HasStream="true">


<PropertyRef Name="Id"/>



SAP extensions to OData Metadata

SAP created a number of extensions to the OData metadata XML. This was necessary as the standard OData metadata is not able to fully describe all the information held in the ABAP Data Dictionary; therefore, the Gateway server will send extra metadata values identified by the sap: namespace prefix.
The following shows a property tag with the additional SAP attributes:

<Property Name="AirlineId” Type="Edm.String” Nullable="false" MaxLength="3” sap:label="Airline" sap:filterable="false"/>

2.6 CRUD Operations

OData for SAP supports CRUD operations (Create, Read, Update, Delete).
To start with, we will cover the simplest two operations that can be performed using OData: ReadEntitySet and ReadEntity (also referred to as QUERY and READ).

  • ReadEntitySet (QUERY) : Returns 0..n entries from a collection
  • ReadEntity (READ) : Returns 0..1 entries from a collection

Both operations are read-only and therefore use the HTTP GET method.


OData defines a RetrieveEntitySet request to search for entities in an entity set. It returns a list of matching entities. The URL only contains the name of the entity set and any needed query string parameters.

Using the example from 2.3, the URL is

OData allows adding parameters to the URL to change the result. Examples for parameters are:

  • $filter – used for passing input parameters, example: $filter=airlineid EQ ‘US’ – Other operators supported, GT, LT, AND, OR, etc.
  • $top – used for getting the top X results, example: $top=5 – returns the first 5 results
  • $skip – used to skip ahead X number of entities in the returned list, example: $skip=5, skips the first 5 results in the list.
  • $top and $skip are often combined to page thru a list, example: $top=5&$skip=5 – returns the second 5 results in the list.

An URL with query parameters looks like this:$filter=Rating%20EQ%204&$top=10&$skip=5

This will return 10 products where the rating is equal to 4. The first 5 results will be skipped.

Please note: Spaces in the URL have to be encoded by using %20 instead. Therefore the string “rating EQ 4” becomes “rating%20EQ%204”.


When reading a single entity, the primary key of that entity must be added to the URL.
In case there is only one key property, the value of the property is sufficient:
In case of multiple keys, the key names must be specified as well:’DE’,bankID=’00000001’)

The result XML from the ReadEntity call is different to the one from the collec-tion, which we saw before. It does not start with a feed, but with the entry tag. This is because the ReadEntity call will always return maximum one entry.

Both the ReadEntitySet and ReadEntity operations can be executed by calling their URL with a modern webbrowser.

2.7 Insert Entity Operation

As the name says, the InsertEntity operation creates a new entity. To execute the InsertEntity operation, HTTP POST has to be used. The URL used to exe-cute the InsertEntity operation is the exact same used for executing the ReadEntitySet operation.
The request Header must include the attribute x-requested-with. The content of this attribute must contain the Atom Entry that represents the business object to be created. The XML would like this:

<atom:entry xmlns="">      <atom:author/>   <atom:content type="application/xml">          <m:properties>        <d:CategoryName>Dessert Topping</d:CategoryName>              <d:Description>Toppings for desserts</d:Description>           </m:properties>  </atom:content> </entry>

Successful execution of the operation returns HTTP 201 status code along with the location of the newly created entity. The location will be send as a header attribute of the HTTP response and contains the URL, with which the new enti-ty can be accessed.

2.8 Update Entity Operation

The UpdateEntity operation updates an entity. It needs to be executed via HTTP PUT. The URL used to execute the UpdateEntity operation is the exact same used for executing the ReadEntity operation.
The Request Header most include the attribute x-requested-with the business data of the entity that should be updated. The XML looks similar to the one in 4.3.2.
Successful execution of the operation returns HTTP 204 status code with no data in the response body.

2.9 Delete Entity Operation
The DeleteEntity operation deletes an entity. It needs to be executed via HTTP DELETE. The URL used to execute the DeleteEntity operation is the exact same used for executing the ReadEntity operation.

Successful execution of the operation returns HTTP 204 status code with no data in the response body.

3 Summary
OData is an open and standardized protocol for exchanging data. It is used by SAP in the NetWeaver Gateway to expose business data that is stored within an SAP ABAP system. OData builds on core protocols like HTTP and commonly accepted methodologies like REST.

OData allows read and write operations like create, read, update and delete.
More information about OData can be found at

SAP Mobile Platform and Sales Plus Webinar

The following is a recording of a webinar that we did together with our customer Zedach and SAP.

It was recorded on 18th September 2014.

You can find more information about Zedach and Sales Plus here:

Lessons Learned from Implementing SAP Mobile Platform and Sales Plus for SAP ERP at Zedach

Please note: This blog is a re-post of a article written by Thomas, that originally was published on the SAP Community Network.

Zedach eG, an organization centralizing the purchasing of thousands of roofer companies, decided to implement a mobile solution to become more efficient. msc mobile was chosen to implement the solution. This implementation, as well as many similar ones we have completed in the past, has taught us some important lessons. But before we get to those, let’s look at the facts for this particular project.

On top of centralizing the purchasing of other companies, Zedach sell all kind of material and equipment that is required to perform their work. This includes hundreds of different tiles, thousands of different screws and nails, solar panels, windows in all sizes, and many more. In total Zedach has a product catalog of about 400,000 items.

To be more efficient, Zedach decided to implement a mobile solution that allows their sales reps to sell via tablets, even without a network connection. The goal was to make the most important transactions from SAP always available. Zedach had the following requirements for the solution:

  • Full offline access to all critical business data, including master and transactional data like sales activities and sales orders
  • Possibility to run the application on iOS, Android, and Windows 8 devices
  • Fast synchronization and high performing application
  • Customer information including contact person, order history, and reports
  • Product information including pricing and any kind of attachment
  • Live data like Available-to-promise (ATP) value for each material
  • T-REX search over all material master data
  • Creating different sales documents like quotations or sales orders on the device
  • Super-user functionality to enable sales directors to access all data of their associated sales reps

Zedach selected msc mobile’s Sales Plus for SAP ERP, an application that runs on the SAP Mobile Platform (SMP) and that is available in the SAP Store. SAP Afaria was implemented in order to manage and secure the mobile devices and to use it for application deployment as well. As final piece to the puzzle, SAP Business Objects Mobile was integrated with Sales Plus to display some of the required reports and to allow the user to jump from Sales Plus directly into the selected report in the Business Objects Mobile app.

We did a lot of similar implementations in the past and, based on those experiences as well as on what we learned at Zedach, we wrote a list of lessons learned, that should help you tackle your mobile implementations:

  1. Requirements Management: A big challenge was to merge the different requirements of all sales departments into one comprehensive solution based on Sales Plus. Since Zedach is a registered cooperative, all sales departments were organized in different enterprises. Therefore, the analyses and design phase of the project was extremely important to fully understand the customer requirements. This allowed us to brief the developers in detail upfront.
  2. Stakeholder Management: Getting the customer’s sales departments involved very early in the project ensured that we got a high acceptance from them. In general we recommend involving the business and key users as early as possible.
  3. Project Management: We executed the project based on our msc mobile project management methodology, a structured way of planning, managing, and executing projects in an agile world. Our methodology takes the best out of PMI-based project management extended with agile components, like running several sprints. This enabled us to deliver early and often. The feedback that we received after every sprint was very helpful to plan the following phases.
  4. Test Management: Based on the agile characteristics of this methodology, testing is a very important pillar closely following development. The user acceptance test (UAT) was a full success. Hardly any bugs were identified in this late stage of the project. Such a smooth UAT is a major driver for a smooth go-live.
  5. Steering Committee: Another reason for this project’s success was the correct identification of all decision makers and appropriate communication to them. In regular meetings they were asked for feedback about current developments. The results after each sprint were introduced to them as well

Zedach successfully went live with the solution in April 2014 and has been using it since then. In the meantime we have implemented many new features and upgraded the landscape to SMP 2.3.3 and Sales Plus 1.1.

Lessons learned: Migrating an MBO-based application to an OData Offline App with SMP 3.0 and Kapsel

Before diving deep into this lessons learned blog, I first want to give you some context and background information. We at msc mobile have a product called Sales Plus for SAP ERP. It’s an MBO-based application connecting via SAP Mobile Platform to SAP ERP to enable sales representatives to do their daily business on a mobile device, either on tablets or smartphones. So the user is able to see and manipulate all kind of relevant master data (Customers, Contacts, Materials, etc.) and transactional data (Sales Activities and Sales Orders) in an offline mode. Just by hitting a synchronize button the online connection is made to SMP and the changes are transferred to SAP. Sales Plus is available on the SAPStore and the Apple AppStore.


To enable cross-platform support, Sales Plus was designed with a container approach: all business logic is implemented with HTML5 and JavaScript (jQuery), whereas native code generated with SMP based on the MBO data model is integrated to handle synchronization and enterprise grade features, e.g. user and security handling. Apache Cordova enables the communication between the generated native layer and frontend layer.


SAP made a tremendous shift within their mobile platform’s technology stack. From SMP 2.3 to SMP 3.0 the entire stack was redesigned, from this MBO approach to a SAP Netweaver Gateway support model based on OData. With the brand new Support Packs (Server Runtime: SP05, SDK: SP04) SMP 3.0 enables offline OData support, which was the reason for us at msc mobile to decide to migrate the entire app.

Now let’s take a deeper look for each layer what a migration means in detail:

  • In SAP ERP all RFCs (Remote Function Calls) need to be replaced by a single SAP Gateway service. A great feature in SEGW (Gateway Service Builder) is the creation of Entities and EntitySets out of predefined ABAP dictionary structures. Since all Sales Plus interfaces are based on those structures, it was very easy to generate the data model. Enhancing the data model with Associations provides the possibility to navigate between Entities (e.g. Customer –> Contact).
    Much of the ABAP code for creating, updating, and deleting Entities could be reused during redefining the corresponding methods of the generated Data Provider Class. The biggest challenge was to rewrite the ABAP code for getting EntitySets. In the MBO-based version SMP was fetching all necessary data for all mobile users based on a predefined schedule. The concrete data distribution was determined with synchronization keys. But in the context of SMP 3.0 and OData, each user is connecting to SAP directly when refreshing data. Therefore, the logic needed to be adjusted to get only the user’s data at each call.
  • In SMP’s Gateway Management Cockpit the SAP Gateway service needs to be defined first. In the Administration console the app must be created using the Gateway service defined before (hint: select “Internal” to improve performance). After specifying all other values like Authentication etc. you could already save and close. In Offline tab you could provide additional settings to manipulate SMP’s offline behavior (when database is created etc.). But if you don’t differ from default values, there is no need to upload a settings file.
  • In Cordova / native layer there was no need to change much. Just adding the required Kapsel plugins like LogonPlugin, EncryptedStorage, OData Offline, etc. did the job. The reuse of msc mobile own Cordova plugins was no problem at all (e.g. separate plugin to handle material pictures synchronization with a separate file server).
  • In HTML / JS the entire frontend business logic could remain as is. Just the data retrieval needed to be adjusted. Instead of communicating with own Cordova plugins to get and send data, now everything can be done directly in JavaScript by doing HTTP-Requests against the OData services. All requests, either online or offline, have the same format. Therefore, the developer doesn’t need to go different ways depending on current internet connectivity. Dealing with Offline Stores (based on OData Kapsel plugin), the developer can trigger the data get (refresh) and data send (flush) manually. So the user still works offline all the time, until he/she clicks on synchronize to trigger the corresponding refresh and flush operation.

But due to the fact that those offline capabilities were added recently (see SP’s stated above), unfortunately some features are not supported yet:

  • There is currently no possibility to use Kapsel Offline OData plugin in combination with Relay Server. Hence, a connection with VPN must be established to connect to SMP directly.
  • To enable searches we tried to combine several “substringof(‘search_term’, attribute) directives within one filter expression. Unfortunately, this is currently not supported or is a bug. It’s working only with a single substringof statement.
  • When trying to run a deep insert, you will fail. This must be done with a batch call.
  • Some of you might know the “submitPending()” function from MBO-based native apps to identify instances to be synchronized. This is a concept not implemented yet. So all OData create / update / delete calls directly take effect in the local database, and therefore will be synchronized at next flush. There is currently no possibility to define which instances should be synchronized, and which should not.

I hope this gave you a good impression what it means to migrate an MBO-based app to SMP 3.0 using OData services. It definitively makes sense to switch to the new technology stack. In former times it was a horror to do any change to the SAP interface in use, since this required to touch the MBO data model, generate new code, embed this code, and then finally do the change in Cordova plugin etc. Now you can easily change the attribute in SEGW, regenerate Data Provider Class – that’s it!

Another big advantage is the decreased load on the backend. A scheduled refresh of all data was leading to run both systems, SAP and SMP, with heavy load. Now with each user connecting directly to SAP via SMP Integration Gateway, flattens the load over the business day.

In summary I can say, the entire migration went faster than initially planned. The Kapsel plugins are increasing the development performance by far. I am really excited what SAP will provide with the next SP releases. Looking forward to get Sales Plus running offline on Windows 8!

Thomas Weber, Product Manager Sales Plus for SAP ERP

Sales Plus for SAP ERP at Sopharma Trading

Sopharma Trading, one of our Sales Plus for SAP ERP customers, presented their mobile sales implementation together with our partner Sqilline at the SAP Forum Bulgaria in Sofia.


On top of the SAP Mobile Platform,  Sqilline was able to implement Sales Plus in a matter of weeks and add customer specific enhancements to the solution. This includes:

  • Promotions and Conditions
  • Header Discounts
  • Add bundles to Sales Orders
  • Translation of the user interface into Bulgarian

Sqilline also changed the look and feel of our app to fit the corporate identity of Sopharma Trading. Here are a few example screenshots:

Sopharma Trading is using Sales Plus on iPads.