OData Integration on SAP NetWeaver Gateway : Batch Operation Usage

Business Scenario

There may be certain scenarios wherein instances may logically bind together and requires to be handled or processed in conjunction within the same logical unit of work. Take for instance a sales order, wherein an update of two or more related firm entries may be required and ought to be processed together in a single request (all or none).

SAP NetWeaver Gateway can be used to process such scenarios possessing the power to accomplish multiple operations in a single request.

It’s a known fact that Gateway provides an OData API into a SAP system (assuming that you had worked earlier with SAP Gateway). This uniform interface supports a given set of operations like Create, Read, Update and Delete and lets you process a single operation per HTTP request.

However, based on the business requirements, it may become pertinent for clients to send multiple operations in a single HTTP request. Commencing with SP04, SAP NetWeaver Gateway offers the capability for client operations to batch multiple operations into a single HTTP request, enabling a sequence of retrieve operations and/or modify operations with only one request.

Pre-requisites

In order to start batching multiple operations, you need to understand few pre-requisites, which are outlined as follows:

• Access to SAP NetWeaver ABAP 7.02 SP7 or system with higher configuration, having SAP NetWeaver Gateway ABAP add-ons installed.
• Availability of SAP delivered RMTSAMPLEFLIGHT service or other Gateway services that are configured to accept requests.
• Installation of backend SAP ECC 6.0 or higher version along with the IW_BEP Gateway add-on (optional, in case the service data arrives from a separate backend).
• Configuration of connections between SAP NetWeaver Gateway system and backend SAP application (optional, in case the service data arrives from a separate backend).
• Google Chrome with “Advanced Rest Client” extension or other compatible REST client that can send RAW HTTP requests.
• Basic understanding of ABAP development.

Introduction

OData batch requests enables binding of multiple operations into a single HTTP request payload. Certain parameters like components of a batch request, how the request gets handled and the components of the batch response have major differences with respect to the components and processing of a simple and single operation of OData request.

There is one major difference between OData batch request and a normal OData request. In OData batch request, the batch request is represented as a Multipart MIME v1.0 message as specified in RFC2046 (MIME networking protocol). This standard format enables multiple parts of various content types to be denoted within a single overall request.

Components of a Batch Request

Batch request consists of two components:

• Batch request header
• Batch request body

Batch request header

Batch requests are sent as a single HTTP POST request to the batch endpoint of a service. The batch endpoint of a service serves as a base service URL attached with “$batch”. Let’s take an example. The batch endpoint for the sample RMTSAMPLEFLIGHT service is:
http://:/sap/opu/odata/iwfnd/RMTSAMPLEFLIGHT/$batch.

The batch request must consists of a Content-Type header that specifies a content type of “multipart/mixed” and a “boundary” specification. The boundary specification is inserted in the body of the request to mark the commencement and termination of each part of the batch request – segregating the different operations contained in the request.

While using HTTP POST method, a CSRF (Cross-Site Request Forgery) token is required when sending the request

Batch request body

The body of a batch request is comprised of an ordered series of retrieve operations and/or change sets. Retrieve operations are generally Query or Read operations executed with the HTTP GET method. When you modify such operations, they are referred as “Change Sets” in OData batch processing terms. Change Sets can consist of Create, Update or Delete operations executed using the POST, PUT and DELETE methods.

In the batch request body, each retrieve request and change set is denoted as a different MIME part and is separated by the boundary marker defined in the Content-Type header of the request. The contents of the MIME part that represents a change set is itself a multipart MIME document with one part for each operation, making up the change set. Each MIME part denoting a retrieve request or change set within the batch includes both Content-Type and Content-Transfer-Encoding MIME headers. The batch request boundary is the name specified in the Content-Type Header for the batch.

Batch Response

Batch response consists of two components:

• Content Type Header that specifies the content type of multipart/mixed.
• Batch boundary specification that may be different from the batch boundary used in the corresponding request.

A body of the batch response consists of a response for each retrieve request and change set, as existed in the associated batch request. The order of responses in the response body tally with the order of requests in the batch request. Each response consists of a Content-Type header with application/http value and a Content-Transfer-Encoding MIME header with a binary value. The formatting of response for a retrieve request is exactly the same as it would have been displayed outside a batch.

The body of a change set response could be:

• A response pertaining to all the successfully processed change requests within the change set.
• Formatted exactly as it would have been displayed outside a batch.
• A single response denoting a failure of the complete change set.

However, at present, content ID referencing in a change set is not supported for $batch.

How are operations handled in batch requests?

Retrieve operations and change sets are handled differently by Gateway.

Each retrieve operation like Query or Read within a $batch request will be transferred separately from SAP NetWeaver Gateway hub system to the provider application at the backend for processing.

On the contrary, since every change set is to be treated as a single logical unit of work (LCW), all operations of a change set will be sent at a single instance from Gateway to the provider application at the backend system for processing. The Gateway system collects results from all the operations and subsequently sends these results as one HTTP response to the OData consumer.

Additional Application API for $batch

For executing retrieve operations, there is no requirement of special handling. However, in order to ensure the “all or nothing” character of a change set, there are two additional methods for changing set handling in interface /IWBEP/IF_MGW_APPL_SRV_RUNTIME. The two additional methods are:

• /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN
• /IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_BEGIN

All operations within a change set must be considered as a logical unit of work. Hence, a provider must not issue COMMIT WORK or ROLLBACK WORK while processing the change sets. Otherwise, the framework will terminate the change set processing. In case the change set consists of only one operation, the check of Commit or Rollback is deactivated.

/IWBEP/IF_MGW_APPL_SRV_RUNTIME~CHANGESET_END

The provider can update the database only if it updates all modifications of a change set within the internal tables. A COMMIT WORK will be issued by the framework at the end of this API.

Mobile Enterprise Predictions for 2015

International Data Corporation (IDC) has hosted the IDC FutureScape for mobile enterprise predictions for 2015 Web conference. The session provided organizations with insight and perspective on long-term industry trends along with new themes that may be on the horizon.

The Predictions Web conference series and accompanying IDC FutureScape reports are designed to help company leaders capitalize on emerging market opportunities and plan for future growth.

PREDICTIONS FROM THE NEW MOBILE ENTERPRISE APPLICATIONS AND SOLUTIONS FUTURESCAPE INCLUDE:

1. IT organizations will dedicate at least 25% of their software budget to mobile application development, deployment, and management by 2017.

2. Difficulties linking mobile platforms to existing databases will cause 45% of mobile enterprise app initiatives to be delayed or go over budget in 2015.

3. Thirty-five percent of large enterprises will leverage mobile application development platforms to develop and deploy mobile apps across their organizations in 2015.

4. The number of enterprise applications optimized for mobility will quadruple by 2016.

5. Thirty to 40% of organizations deploying more than five mobile applications in 2015 will realize substantial business agility benefits by establishing an API tier in their enterprise IT architecture.

6. Over 50% of large organizations will invest in enhanced enterprise mobility management (EMM) capabilities to secure apps and data in 2015.

7. By 2017, 100% of the line of business (LOB) apps in customer-facing roles and 75% of LOB apps in internally-facing roles will be built for mobile-first consumption.

8. IT departments will require major reorganizations by 2016 to assume broker-integrate-manage as well as service orchestration functions.

9. Competitive necessity will supersede productivity and efficiency for 50% of mobile enterprise app development in 2015.

10. By the end of 2015, only 15% of large organizations will have adequate mobile security governance for process and policy.

“The number of enterprise applications optimized for mobility will quadruple by 2016, driven both by competitive necessity and rapidly evolving technologies that support faster and more secure enterprise ‘appification’,” said John Jackson, program vice president for Mobility Research at IDC. “The benefits from efficiencies and business innovation on the back of this app explosion will transform industries and markets. At the same time it is clear that the path to broader mobilization of business processes is still complex. For this reason, we offer this FutureScape to help enterprise mobility stakeholders shape their strategies, decisions, and investments. Organizations that execute effectively will be positioned to enable innovation across all facets of their business.”

The IDC FutureScape report that this Web conference is based on will be published and available within the 24 hours. To learn more, visit www.idc.com/Predictions2015.

Mobile SSO for SAP Fiori with SAP Authenticator

Overview of SAP Fiori

SAP Fiori is a new age experience (UX) for SAP, that is revolutionizing the way applications are built, taking the user experience to new heights. It combines modern design principles providing a holistic and a consistent experience across variety of devices. With SAP Fiori, you can accomplish a variety of productive tasks including getting quick insight-to-action anytime and anywhere.

There are a variety of apps that are currently applying the SAP Fiori UX to provide enhanced user productivity and personalization for customers, who use SAP Business Suite on any database and SAP Business Suite powered by SAP HANA. Enterprises that have implemented a single sign on (SSO) solution for the SAP Business Suite can give the same ease of use to their Fiori users with several SSO options.

Implementing Mobile SSO for SAP Fiori with SAP authenticator

On November 3rd, 2014 SAP released a latest support package (SP04) for Single Sign-On 2.0 – a mobile SSO solution that is perceived as a straightforward authentication mechanism for favorite applications and trusted websites on mobile devices. It offers simplicity for your SAP Fiori users without compromising the security for your company.

This solution is based on Time based One-Time Password (TOTP) algorithm, which is of the open standard RFC 6238. This algorithm computes a one-time pass code from a shared secret key and current time. With the respective user name and pass code, the authentication to the Identity Provider triggers IDP initiated single sign-on mechanism. For TOTP client, SAP authenticator is the mobile application, which is available for iOS and android platforms. SAP Authenticator offers password protection. The password is defined during the installation of the application, it is used only for the encryption/decryption of the secret key, and it is not stored on the device. The password offers additional level of security, that is not available with the other similar OTP generator applications existing on the market. Mobile SSO implementation with TOTP is easier to setup and support compared to, for example, a Mobile SSO implementation based on client certificates, where a Public Key Infrastructure is necessary. Mobile SSO with TOTP could be enabled easily also for scenarios that allow a “Bring Your Own Device” (BYOD) policy, where the transfer and the storage of client certificates is difficult or impossible.

Once you implement this solution, you will have the flexibility to use Fiori applications, bookmarked on your device after a single click. Once you click on the respective Fiori application bookmark, the SAP authenticator creates a pass code and a URL with respective parameters. Next, the SAP authenticator sends this URL to the browser, wherein the browser opens the URL that triggers the single Sign-On. On the other hand, the Identity Provider checks the entered credentials and if the authentication is successful, issues a SAML 2.0 assertion for you and for the respective service provider (SAP Fiori). In the final step that refers to the HTTP-POST binding response, the SAP Fiori application gets securely opened on your mobile device.

Key Take aways

• Greater simplicity for end users – high level of user experience
• Enhanced security for your organization
• Save costs due to minimized number of password related IT tickets
• Increased employee productivity (only one single password and less typing)
• Built on responsive design principles
• Utilizes SAP UI5 and SAP NetWeaver Gateway to provide a consistent and a seamless end-to-end extensibility
• Leverage your current SAP investments by offering quick value for over 85% of your users.

Conclusion

From the above discussion, it is obvious that Mobile SSO with SAP Authenticator has a major role to play in ensuring enhanced corporate security, while providing a consistent, simple and a holistic consumer grade experience across a variety of devices – desktop, tablet or a smart phone. Organizations worldwide are adapting to this new technology to take consumer mobile user experience to the new level with perceived business benefits – improved user productivity and substantial cost savings.

If you would like to request a demo for the “Fiori SSO with SAP Authenticator”, please click on the link below. Alternatively, if you would like to discuss with an Innovapptive associate, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.

Seamless File Upload and Download to SAP using SAP NetWeaver Gateway

Introduction

SAP NetWeaver Gateway is a technology that offers a seamless platform to connect devices, environments and platforms. It enables creation of cutting edge solutions with world class UX providing the potential of SAP business software into new experiences including social and collaboration environments, mobile, tablet and rich internet applications. It offers the flexibility to use any programming language or model to connect with SAP applications by leveraging REST services and OData/ATOM protocols, eliminating the necessity to have the knowledge of SAP.

This blog provides step by step instructions of how you can leverage Innovapptive’s function modules to upload files for any document and later download the files to SAP server, appreciating the technology behind this approach. Before we get into the actual process of file upload/download process, let’s get a brief technical background of the function modules behind the upload/download process.

There are two function modules on the SAP server to enable the file upload/download process:

1. /INVMWL/FM_WI_ATTACH_DISPLAY (Display Attachments – file upload): In this module, you can define the input parameters (IM_OBJKEY and IM_APPID) to get the required attachments for that file.

2. /INVMWL/FM_WI_ATTACH_DOWNLOAD (Download Attachments – file download): Once you get the required attachments, the next step is to fetch the data from the attachments. This is accomplished in this module, wherein you can define 3 parameters (IM_APPID, IM_OBJKEY and IM_OBJID) to retrieve the information available in each of the attachments.

Let’s assume, there is a sales order for which you need to attach multiple files. Technically speaking, here sales order is referred by the object key and respective files that you want to attach are referred by its respective object ids. Note that each document can have a one reference id. First, let’s understand the high level steps for the file upload/download process:

File Display

STEP 1 – TASKS TO PERFORM ON SAP BACK-END SERVER

1. Pass the parameter names (IM_OBJKEY and IM_APPID) to get the attachments.

2.  Read the information in the documents and convert into binary code.

STEP 2 – TASKS TO PERFORM IN RFC (SAP NETWEAVER GATEWAY) FOR 

1. Replicate the entity structure (as defined /INVMWL/FM_WI_ATTACH_DISPLAY module) and map the services to get the list of attachments.

2. Replicate the entity structure (as defined in /INVMWL/FM_WI_ATTACH_DOWNLOAD module) and map the services to download the data. Now, let’s move on to the high level steps:

File Upload and Download

STEP 1 – TASKS TO PERFORM ON SAP BACK-END SERVER

1. Get the attachments for the file (refer figure 2) by passing the input parameters. For this, follow the below logic:

a. Based on the parameters (Object key & Appid) that you pass, select the business object.

b.  Call the functional module BDS_ALL_CONNECTIONS_GET with the following parameters:

 Input for this functional module

Classname = Business Object

Classtype = BO

Objkey = IM_OBJKEY     

Output for this functional module

Number of attachments’ component ids

c. Loop the component ids.

d. Call the functional module:SO_DOCUMENT_READ_API1

e. Enter the component id to get data from each of the attached documents.            

Note: If there are multiple attachments, multiple object ids gets retrieved for a single object key (Ex: Sales Order)

f. Endloop.

Figure 1: Import Parameters

Figure 2: Export Parameters

2. Read and convert the information in the files to binary code (Refer figure 4),

a. Call the function module SO_DOCUMENT_READ_API1.

b. Get the attached document data in string format.

c. Call the functional module SCMS_BINARY_TO_XSTRING to convert to xstring from binary.

Figure 3: Import Parameters

Figure 4: Export Parameters

STEP 2 – TASKS TO PERFORM IN RFC (SAP NETWEAVER GATEWAY) FOR 

1. Replicate the entity structure using RFC module and map the services to get the list of attachments.

a. Create the entity structure in the Properties screen. This generates a URL.  

Figure 5: Replicate Entity Structure

b. Map the services for query operation for module: /INVMWL/FM_WI_ATTACH_DISPLAY

Figure 6: Map the Services

2.  Replicate the entity structure and map the services to download the data.

a. Replicate the fields in the Properties screen.

Figure 7: Replicate the entity structure to read the data

b. Map the services (Operation GetEntity) in the /INVMWL/FM_WI_ATTACH_DOWNLOAD module, which generates a URL where you      can view/download the data of the attachments.

Figure 8: Map the services to download the data

Contact us today to learn how you can leverage our custom mobile development accelerators to reduce your app development times by over 50%. Read more here – Custom Application Development. Contact us by sending an email tosales@innovapptive.com

SAP Web IDE (Integrated Development Environment) for SAP Fiori and SAPUI5 Applications

SAP Web IDE (Integrated Development Environment) is a Web-based development environment designed to support the end-to-end application lifecycle for SAP Fiori and SAPUI5 applications

In today’s market scenario, the key to business success lies in agility in multiple dimensions. One of the key aspects of agility is to design, develop and deploy applications swiftly to address the growing expectations of the users to have amazing user experiences. Using SAP Web IDE, developers and power users alike can swiftly deploy new-age applications that leverage SAP HANA and SAP HANA cloud platform and is planned to be available as on-premise solution on SAP HANA XS in the future. The pluggable and modular architecture allows to integrate SAPUI5 tools and enables SAP development, partners and customers to add their own plugins.

This web based development environment addresses the application development processes in a comprehensive manner, right from prototype through deployment. SAP Web IDE offers highly efficient tools to easily build and extend apps applying SAP Fiori UX and generic SAPUI5 apps using wizards, templates, drag and drop tools, code editor and much more. Simply stated, SAP Web IDE is a web based environment that lets users to create incredible user experiences swiftly for browser and mobile devices. Apart from that, SAP Web IDE environment also lets users to extend SAP Fiori and UI5 apps (through visual extensibility editor) as well as build new UI5/HTML5 or custom Fiori apps.

Overview of key features

• Offers standard development tools such as code editors wizards and WYSIWYG (“What You See Is What You Get”) tooling that are optimized for building responsive HTML5 apps with SAPUI5.
• Consists of certain standard templates – SAPUI5, Fiori and SAP WEB IDE plugin; and offers flexibility to create your own template (custom template).
• Supports the E2E application life cycle that covers UI design, development, testing, deployment and customer extensions for responsive SAPUI5 apps.
• Code based environment – the tool never gets in the way of the developer.
• Both SAP and non-SAP developers can design, build, test and deploy responsive SAP UI5 and Fiori like apps using SAP HANA or Gateway OData services.
• Develop once and deploy anywhere – can be run on any device including mobile and tablet.
• Instant preview feature that lets you launch the application in the browser at different resolutions and in multiple languages, using real or mock data.
• Collaborative development and project persistency that lets developers to collaborate on specific files via JAM integration (not available in the beta release in June 2014).
• Provides extensible and modular architecture that lets you add your own plug-in/template via wizards and templates.

Why SAP Web IDE

• Enhances development productivity – offers easy to consume development environment.
• Minimizes IT infrastructure and administration efforts.
• Cloud based (hosted on SAP HANA cloud platform), eliminating initial installation and configuration of local IT infrastructure.
• Access development projects anytime and anywhere.
• Holistic development environment with incredible UI.
• Drag-and-drop (WYSIWYG) editors – simple to use with less technical complexity.
• Tighter collaboration between developers, business experts and designers.

Summary

SAP Web IDE serves as a great productivity tool for developers, designers and business experts. With its cutting edge embedded tools covering end-to-end development process, it enables you to rapidly design, build and deploy web applications based on SAPUI5 and also supports you in extending SAP Fiori apps. Some of the key advantages of leveraging SAP Web IDE include enhancement of the development productivity, low infrastructure costs and ensuring tight collaboration between designers, developers and business experts. Hence, SAP Web IDE lets you develop and deploy applications with greater agility, while providing amazing end user experiences.

If you would like to request a demo for the “SAP Web IDE”, please click on the link above. Alternatively, if you would like to discuss with an Innovapptive solution expert, you can reach out to us by emailing us at sales@innovapptive.com or you can reach a sales representative at (713) 275-1804.