Mobile and cloud computing open the way to open source

A business process in a company is often managed across several stations or departments until the process is completed. The employees involved have different profiles - from SAP experts to occasional users.

To make it as easy as possible to integrate occasional users into the business processes, it is advisable to use existing user interface (UI) technologies. This reduces the training period and increases user acceptance.

Technologies such as Microsoft SharePoint are often used. If the information stored in SAP can now be displayed and edited directly and without redundancies in SharePoint, the entry threshold for entering data into the SAP system is dramatically reduced.

The quality and timeliness of data is increasing. However, employees are also increasingly using mobile solutions such as tablets or smartphones. How can these new user groups access the data available in the SAP system as easily and securely as possible?

When dealing with social media platforms, the question also arises as to how innovative new solutions can be created by linking the platforms more closely with business-critical data in the SAP system.

The variant configuration integrated in SAP ERP offers a powerful solution for starting production processes as well as processes in the back office, depending on the configuration selected in the customer order.

In order to simplify the input of the configuration even further, the input option in this study was made possible by an integrated 3D model that immediately visualizes the selected attributes.

Inputs can thus be visually checked and corrected immediately, while at the same time increasing acceptance by end users. Another example is the SAP Citizen Connect solution.

Based on the functions of the SAP system, a mobile solution was created that allows the residents of a city or municipality to send problems or grievances directly from their mobile device to the SAP system. This eliminates the need for intermediate steps such as calling a switchboard with imprecise location information.

This additional information means that a prompt decision based on correct facts is now possible. And the direct feedback back to the reporter increases the motivation to continue reporting grievances in the future that would otherwise remain undetected.

Solutions for non-ABAP

As the SAP system is open, the above scenarios have been technically feasible for a long time. However, the disadvantage was that point-to-point solutions were used in each case.

In addition, the developer of the non-SAP solution needed in-depth detailed knowledge of the SAP system. Unfortunately, developers who have a good level of knowledge in both SAP and non-SAP development languages are not always available.

As a result, projects become longer or more expensive and maintenance can only be provided with difficulty, as the front end in particular continues to develop dynamically. Existing SAP customers and partners are usually very familiar with the ABAP programming language.

However, ABAP skills are not very widespread in other developer communities, where C, Java, Objective-C, PHP or C# predominate. As a result, companies today typically have two parallel organizational structures: one department to support the SAP systems and another to deal with non-SAP issues.

The aim for NetWeaver Gateway was also to reduce the communication barriers between the two teams. In the search for a tool that could be understood by both SAP and non-SAP experts, the REST-based protocol OData was chosen. This protocol is currently being converted into an Oasis standard in order to accelerate further dissemination.

SAP NW Gateway

NetWeaver Gateway provides a tool that accelerates and standardizes the development of required REST services in ABAP-based SAP systems.

Many activities that are not directly related to the development of the service are taken over by the developer, such as supporting dialects (XML or JSON), preparing messages, analyzing messages and central monitoring. A typical process for the development of a new user interface can look as follows (simplified):

• In a joint workshop between the users - usually represented by a key user, the user interface expert and the SAP backend expert - the desired new user interface is defined and outlined.
• Requirements for the SAP backend and frontend are then derived based on the results of the workshop. These requirements can be documented in an entity-relationship model. This document forms the starting point for the next steps. It can be imported into an SAP system as well as into the development tools for front-end development.
• The necessary developments are now being carried out in both the backend and the frontend.

OData is coming

The OData protocol is based on open standards such as HTTP, XML, JSON or AtomPub. The already known and HTTP-defined operators such as Get, Post, Put, Patch or Delete always have the same meaning.

The REST-based architecture also allows developers who have no special SAP knowledge to start developing with standard tools without a great deal of training.

Definition of an OData model: An entity-relationship model serves as the basis for defining the service. Each defined service provides a metadata document. This metadata document, which has the same structure in each case, abstracts and aligns the data from backend systems.

If, for example, the model of a planned user interface is made up of the objects product, manufacturer and product category, the desired model is then modeled in an XML document (EDM). In order to transfer the model into OData, knowledge of the underlying concepts of OData is required:

• Entity set: In the example above, "Product" would be an entity set. It is comparable to lists or table entries. All entries (or entities) in an entity set have the same entity type.
• Entities: are instances of the entity type. They can be structured and have a key element (entity key). The structure of an entity is defined by properties. An entity can be addressed individually via the key. Several entries can be returned via a search.
• Entity Key: consists of properties. This key is important in order to uniquely identify individual entries. It is also required to define associations between entity types.
• Association: This is the named connection between two entity types. Each association consists of two endpoints that define the entity types and the cardinality (1:N, 1:1).
• Navigation property: It is used for navigation between entities and is linked to the association and the entity type.
• EntityContainer: All entity sets that belong to a service are summarized here.

This methodology can be better illustrated with the example outlined above: The properties of the supplier are: ID (Entity Key), Name, Address, Concurrency and Prodcuts (Navigation Property).

The EntityContainer with the name DemoService consists of the following EntitySets and associations between the various objects (which are not listed here): Products, Categories and Supplier. A model is defined based on these principles.

Operations based on the model: If this model is defined, operations can be performed on the model at runtime. These operations can be, for example, search, update, delete.

A list of all products can be accessed via the URL http://services.odata.org/OData/OData.svc/Products/ display. This list can be further restricted by adding a search parameter such as $top.

The address http://services.odata.org/OData/OData.svc/Products/?$top=3 now only displays the first three products. The response consists of an XML or JSON document with the name of the properties and their values.

In addition, the navigation properties in the response are marked with
output. The linked objects (category and supplier) can now be called up directly using their own URLs.

Simple navigation using the returned URLs is now also possible for developers who do not have detailed knowledge of the backend system used. Category and supplier details are now directly accessible.

Query operations: Many user interfaces are based on similar, simple patterns. Very often these patterns start with the input of a search. OData has various ways of formulating a search. All operators are preceded by a $.

A query of all products with a price below 20 is then formulated as follows: http://services.odata.org/OData/OData.svc/Products/?$filter=Price le 20.

If only the values Price and Name are required from this result, you can use $select to specify the columns of the response: http://services.odata.org/OData/OData.svc/Products?$select=Price,Name.

The responses can also be sorted using $orderby. Of course, this command is only useful when outputting a list. In this example, the products are sorted in order:

Using $top and $skip, certain areas of a larger result can be reduced to individual packets, which are then transferred as required with low resource consumption.

http://services.odata.org/OData/OData.svc/Products?$skip=2&$top=2&$orderby=Rating transfers the third and fourth row of products, sorted by rating.

From definition to implementation

Once the desired behavior has been defined, the implementation of the required service can begin in the SAP system. In order to provide the developer of the required service with the best possible support, NetWeaver Gateway offers support for the various use cases.

A detailed distinction is made between the definition and implementation of a service. The following steps all take place in the Service Builder. This is the central interface within NetWeaver Gateway for service definition and service implementation.

To define a service, the data model is defined according to the OData syntax described above. The data model can be defined declaratively by manual input.

The Service Builder supports the definition here with a folder structure based on the OData data model, in which the categories such as relations or entities can be entered in tabular form. Alternatively, the data model can also be defined by importing a data model from outside the SAP system.

In addition, the data model can be defined based on structures and information from the underlying SAP system (DDIC/RFC or BOR interfaces) and by referencing object models in the SAP system. Many objects are developed internally in an object-oriented manner.

It is therefore relatively easy to transfer these internal objects into OData Services. Examples here are PLM, EAM or CRM. But queries from Business Warehouse or views from Hana can also be easily converted into an OData service.

In addition, the implementation is automatically generated at the same time. If a service already exists that was developed via NetWeaver Gateway, a new service can be developed based on the old service.

This can be useful if, for example, an extension or change is necessary but the original service cannot be changed.

Particularly for scenarios based on BW, the queries contained in the Service Builder can be converted into OData services using generators. As not all queries are suitable for use as OData services, the queries must be marked with an Easy Query indicator in the BW Query Designer before being used in the Service Builder.

If the query cannot be converted, this indicator cannot be set. Another option for integrating information from SAP BW is the MDX format. This format can also be converted into an OData service using the generator.

The defined services can now be implemented in the SAP system in two ways: by mapping the OData model to existing function modules in the SAP system such as RFC, BAPI, BOR.

A separate function module can be used for mapping for each method (delete, read, add). Mapping is carried out in the Service Builder in a user-friendly way using drag & drop. Or by manual implementation using the SAP standard tools in ABAP.

The backend plug-in provides a super class, which must then be reimplemented accordingly. Each method (read, delete, search) is developed separately. This method then contains the actual logic, i.e. the coding that reads or updates the corresponding function modules and tables.

If an association between entities was specified when the model was defined - such as from product to category - then this association must also be implemented in the Service Builder.

All implementations and generated coding are created in the so-called customer namespace. On the one hand, this has the advantage that manual adjustments are always possible. This is also supported by a concept of extension points.

On the other hand, the standard tools in the ABAP environment are used for source code management and transport. As a result of the definition and implementation, a functional OData service has now been created.

Once the service has been created, the next step is to activate it. The background to this step is that the service implementation can theoretically be located on a separate SAP system from the central NetWeaver Gateway Server.

Registration makes the service known in the central system and includes it in a central service catalog for OData Services. The user interface for registration and activation also contains tools that are helpful for troubleshooting and testing.

This means that the Service Builder contains all the functions required for definition and implementation in one place, while the user interface for registration and activation contains all the tools for managing an existing service.

User interfaces

Visual Studio LightSwitch: Now that the corresponding service has been implemented or generated in the SAP system, the service can be used directly in various interfaces, depending on requirements.

By using an open standard, there are many options and providers that support the OData format. Microsoft's Visual Studio LightSwitch is worth mentioning here, as it provides an open solution for creating more complex applications based on templates that can be easily extended and adapted after generation.

These templates can also be linked to OData services in the creation wizard. And since Microsoft Excel version 2010, it has also been possible to import an existing OData service into Excel and display the contents in the table view.

Of course, some adjustments must be made during the conversion, so the relations are stored in tables. This requires the installation of the free Power Pivot add-on for Excel 2010.

Although Excel cannot use this option to update the data in the SAP system, it does make it easy to display values and perform Excel-based analyses.

Outside Consumption Tools: Extensions are made available via the SAP Community Network to help with the creation of applications based on HTML5 (jQuery mobile or SAP UI5), Android, iOS, Java, PHP or .Net.

The developer is supported by the wizard-based extensions. This wizard analyzes the OData service in order to identify the relations and attributes, for example. Depending on the user interface technology, list details and sometimes also workflows are available as templates.

In the next step, the developer must define the screens, their sequence and the fields visible on them. The source code is then generated, which can be used as the basis for customer-specific adaptations.

Many elements such as the proxies can then be used directly as the basis for individual programming of the application. With mobile technologies such as iOS or Android, communication initially takes place directly from the app via OData to NetWeaver Gateway.

If the SAP Mobile Platform is used, it is very easy to switch communication to the Mobile Platform in the central proxies, while the rest of the mobile application and the services created in the SAP system can remain the same.

SAP UI5: Many browser manufacturers and producers of tools for creating and maintaining websites are currently working on HTML5. SAP is also active.

As the Walldorf-based company focuses on supporting business-critical processes, HTML5 support has also been optimized.

Using the SAP UI5 framework makes it easier to create HTML5-based interfaces. This is achieved, for example, by providing controls that offer a uniform appearance and simplified creation.

Components used

In simplified terms, the NetWeaver Gateway solution consists of two components, a backend plug-in and the actual gateway server. The backend plug-in contains the functionalities required to integrate directly into the backend.

The most prominent example is the Service Builder as a central development and modeling environment. The Gateway Server contains the server functions. This is where any backend plug-ins come together centrally, where the XML files are generated, responses are received and much more.

Authorizations and access to the SAP system play an important role. The NetWeaver application server ABAP already includes support for many protocols such as SAML 2.0, X.509, Basic Authentication or SSO2 Token.

These protocols can therefore be used directly for communication with the NetWeaver Gateway system. A distinction can now be made between several architectures:

• Installation directly on the backend system: In the simplest installation, both the gateway server and the backend plug-in can be installed directly on the SAP system, whereby the system must use at least NetWeaver version 7.0. The advantage is the low cost. No additional hardware is required. As the NetWeaver Gateway Server requires relatively few resources, many scenarios can already be served in this way.
• Installation on a separate system: If there is more than one backend system, we recommend installing the Gateway Server on a separate server, as the backend plug-ins are still installed in the SAP systems. The various SAP systems now communicate directly with the gateway server. The necessary services are also developed in the backend plug-ins in this scenario.

  This has the advantage that the corresponding logic is located directly in the SAP system. This enables very high-performance development. Only the required data is transferred to the central gateway server.

  Even more complex scenarios such as assigning requests from the gateway server to the correct SAP system are possible - if, for example, each region has its own SAP system.

  This type of architecture can be selected if, for example, increased security is to be provided for external access using a layered defense concept. The NetWeaver Gateway system can also be installed in the Demilitarized Zone (DMZ).

• Without installation on the SAP system: The two options outlined above

Options have the disadvantage that additional software must be installed on the SAP system. In some constellations, it is difficult to install additional software if, for example, a system has been validated according to FDA standards.

In this case, both the backend plug-in and the gateway server can be installed on a separate system. Communication with the SAP system takes place via the interfaces already contained in the system, such as RFC or BAPI.

To be continued ...