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 (http://www.feedly.com) 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="http://www.w3.org/2005/Atom">

<title>UI5 Development</title>

<subtitle>Introduction to SAP UI5</subtitle>

<link href="http://example.org/feed/" rel="self" />

<link href="http://example.org/" />

<id>urn:uuid:60a76c80-d399-11d9-b91C-0003939e0af6</id>

<updated>2003-12-13T18:30:02Z</updated>

<entry>

<title>Introduction to OData</title>

<link href="http://example.org/2003/12/13/atom03" />

<link rel="alternate" type="text/html"  href="http://example.org/2003/12/13/atom03.html"/>

<link rel="edit" href="http://example.org/2003/12/13/atom03/edit"/>

<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>

<updated>2003-12-13T18:30:02Z</updated>

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

<author>

<name>Alexander Ilg</name>

<email>alexander.ilg@msc-mobile.com</email>

</author>

</entry>

</feed>

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 http://services.odata.org/OData/OData.svc.

Example of an OData Service Document

The following shows an example of an OData Service Document:

<service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xml:base="http://services.odata.org/OData/OData.svc/">

<workspace>

<atom:title>Default</atom:title>

<collection href="Products">

<atom:title>Products</atom:title>

</collection>

<collection href="Advertisements">

<atom:title>Advertisements</atom:title>

</collection>

<collection href="Categories">

<atom:title>Categories</atom:title>

</collection>

<collection href="Suppliers">

<atom:title>Suppliers</atom:title>

</collection>

</workspace>

</service>

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: http://services.odata.org/OData/OData.svc/Products

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

Response

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

 

<feed xmlns="http://www.w3.org/2005/Atom" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml"xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xml:base="http://services.odata.org/OData/OData.svc/">

<id>http://services.odata.org/OData/OData.svc/Products</id>

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

<updated>2013-12-01T14:30:27Z</updated>

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

<entry>

<id>http://services.odata.org/OData/OData.svc/Products(0) </id>

<category term="ODataDemo.Product" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>

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

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Category" type="application/atom+xml;type=entry"title="Category" href="Products(0)/Category"/>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Supplier" type="application/atom+xml;type=entry"title="Supplier" href="Products(0)/Supplier"/>

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

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

<updated>2013-12-01T14:30:27Z</updated>

<author>

<name/>

</author>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/relatedlinks/Category" type="application/xml" title="Category"href="Products(0)/$links/Category"/>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/relatedlinks/Supplier" type="application/xml" title="Supplier"href="Products(0)/$links/Supplier"/>

<content type="application/xml">

<m:properties>

<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>

</m:properties>

</content>

</entry>

<entry>

<id>http://services.odata.org/OData/OData.svc/Products(1)

</id>

<category term="ODataDemo.Product" scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>

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

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Category" type="application/atom+xml;type=entry"title="Category" href="Products(1)/Category"/>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/related/Supplier" type="application/atom+xml;type=entry"title="Supplier" href="Products(1)/Supplier"/>

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

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

<updated>2013-12-01T14:30:27Z</updated>

<author>

<name/>

</author>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/relatedlinks/Category" type="application/xml" title="Category"href="Products(1)/$links/Category"/>

<link rel="http://schemas.microsoft.com/ado/2007/08/dataservices/relatedlinks/Supplier" type="application/xml" title="Supplier"href="Products(1)/$links/Supplier"/>

<content type="application/xml">

<m:properties>

<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>

</m:properties>

</content>

</entry>
</feed>

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:id> http://mysapgateway.com/sap/opu/sdata/sap/FlightInformation/Flights</atom:id>

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

<atom:title>Flights</atom:title>

<atom:updated>2011-10-17T16:38:55Z</atom:updated>

<atom:entry>

<atom:category term="FlightInformation.Flight”

scheme="http://schemas.microsoft.com/ado/2007/08/dataservices/scheme"/>

&nbsp;

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

<m:properties>

<d:AirlineId>AA</d:AirlineId>

<d:ConnectionNo>0017</d:ConnectionNo>

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

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

<d:CurrencyCode>USD</d:CurrencyCode>

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

<d:DistanceUnit>SMI</d:DistanceUnit>

<d:FlightTime>361</d:FlightTime>

<d:PlaneType>747-400</d:PlaneType>

</m:properties>

</atom:content>

[...]

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 http://services.odata.org/OData/OData.svc/, you need to call http://services.odata.org/OData/OData.svc/$metadata.

Example

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">

<Key>

<PropertyRef Name="Name"/>

</Key>

<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>

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

<Key>

<PropertyRef Name="Id"/>

</Key>

[...]

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.

ReadEntitySet

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 http://services.odata.org/OData/OData.svc/Products.

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:

http://services.odata.org/OData/OData.svc/Products?$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”.

ReadEntity

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:
http://services.odata.org/OData/OData.svc/Products(0)
In case of multiple keys, the key names must be specified as well:

http://services.odata.org/OData/OData.svc/Banks(bankCountry=’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="http://www.w3.org/2005/Atom">      <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 www.odata.org.

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.

IMG_0952

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.

IMG_0954

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.
    screenshot_01
  • 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.
    screenshot_03
  • 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.

sap_forum_bulgaria

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.

msc mobile Named a Finalist for 2014 SAP® Pinnacle Award

msc mobile Named a Finalist for 2014 SAP® Pinnacle Award in Application Development Partner of the Year Category

 

sap_pinnacle2014_fin_rgb_lgAugsburg— April, 2014 — msc mobile today announced it is a 2014 SAP® Pinnacle award finalist in the Application Development Partner of the Year category.  SAP Pinnacle awards are presented annually to leading SAP partners that have excelled in developing and growing their partnership with SAP (NYSE: SAP) and driving customer success.  Finalists and winners in 21 categories were based on field recommendations, customer feedback and performance indicators in the following five umbrella categories: Run Together (for co-innovation), Run Further (for market expansion), Run Clever (for service delivery), Run Sustainably (for sustainability) and new for 2014 Customers’ Choice.

“We are so proud to be a finalist of the 2014 SAP Pinnacle Award, as it affirms the great work we do for our customers every day,” said Thomas Weber, Product Manager Sales Plus for SAP ERP at msc mobile. “We are completely dedicated to improve the business processes by providing easy to use solutions for the desktop and the mobile world.”

The award recognizes the ability of msc mobile to build innovative solutions based on SAP technologies that address critical customer needs and support SAP technology adoption. msc mobile was recognized as the winner of the SAP Mobile Game On App Contest in January 2014 and is present in the SAP Store with their solution Sales Plus for SAP ERP.

“Being a finalist of the SAP Pinnacle Award is additional motivation for us to continue to create new innovative solutions that help to transform business and help them to run better” said Alexander Ilg, Managing Director of msc mobile.

The SAP Pinnacle awards allow SAP to shine a spotlight on its leading partners that have excelled in their partnership with SAP and in growing mutual business by helping customers run better.

 

About msc mobile

With everything we do, we want to make the work life of people easier. We believe that people should be able to focus on their work, instead of spending their time on administrative tasks, paper or software.

The way we make the life of people easier is by providing easy to use solutions for the mobile world and the desktop. We implement standard SAP Mobile solutions and develop custom applications.

Founded in 2006, winner of the “2014 SAP Mobile Game On App Contest” and finalist of the 2014 SAP Pinnacle Award, msc mobile is an SAP platform partner with a proven track record in enterprise mobility.

 

# # #

SAP and all SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries.

All other product and service names mentioned are the trademarks of their respective companies.

For more information, please contact:

Europe:

Stavros Giogiakas

Stavros.giogiakas@msc-mobile.com

+49 151 46 31 43 01

 

http://www.msc-mobile.com

North America:

Carl Boivin

Carl.Boivin@msc-mobile.com

+1 514.295.9655

 

http://www.msc-mobile.com/press/SAPPinnacleAwards2014_FinalistPR-mscmobile.pdf