SAP Fiori Implementation for SAP EWM

Project Details

We built a custom SAP Fiori Warehouse Management transactional app. This video is a demo of  a Warehouse Management app developed as part of CSC UK  and India SAP Mobility team. It is intended to perform post goods movement for Handling Units with reference to deliveries. It would be used by Warehouse workers at the time of unloading and loading operations. To build this app we have also used a third party application ‘Apache Cordova’ to access the smartphone camera for scanning the Handling Units.

“SAP Fiori App for WM ” is a Transactional Fiori Application, first of its kind with regards to Warehouse Management, built to assist warehouse workers in their daily activities.

This WM app is primarily focused on the daily activities that a Warehouse worker would perform using his/her RF Device (which costs at least £1000 per device).  RF devices receive data via radio waves directly from the SAP System and transmit the results back to the system. This WM App, being an “SAP Fiori App” is capable of accessing SAP system just like the way RF device does; thus can very well replace RF Device which brings up huge business advantage with it, by lowering the capital costs spent on RF devices and for its maintenance. It is estimated that an Automobile Company, such as FORD Motor Company, with 25 Warehouses across a region, which uses approx. 100 RF Devices per warehouse can save a minimum of £2.5 million (excluding maintenance costs).

The WM app is developed to perform the following Warehouse Processes:

1. Goods Receipt
2. Goods Issue

The App deals with the Warehouse Processes using the Handling Unit by performing “Goods Receipt” at the warehouse against the inbound delivery, and “Goods Issue” against the outbound delivery.

The core idea behind this WM app is to enrich a Next-Gen Smart Warehouse utilising Fiori and also increase user adoption by providing better user experience.

Ideally, in a POV (Proof of Value) for any DB and HANA DB Fiori Implementation Project there should be  following people

Fiori Configuration Consultant – Fiori Consultant – Fiori Consultant should be able to identify all the UI components that need to be downloaded from the service marketplace. He should also be able to assign the right roles to the right users through PFCG, maintain and activate service and have reasonable browser debugging skills to navigate issues. These skills are enough for standard app deployment. For custom app he or she would need more technical skills such as JQuery, Json and screen designing.

SAP BASIS / Netweaver Consultant – System Administrator who can install all relevant components, set up roles and make the Netweaver Gateway connection

HANA Consultant – HANA Technical consultant who can set up the HANA architecture for apps that run on HANA DB (Analytical Apps)

MDM Expert – To make sure the apps run effectively in a secured network it is essential to have an MDM specialist either from the client side or from the solution provider. There could be any third-party MDM solution that needs to be incorporated in the architecture. It is very important to understand the security requirements from the client.

Lesson Learned 2 – Apply all the SAP notes before implementation

SAP Notes are listed in the installation guide. http://help.sap.com/fiori

If you do not apply SAP Notes, you might have to spend a few weeks troubleshooting, searching and finding the root cause of the app not working. Applying SAP Notes may take 1 but would save your 2-3 weeks troubleshooting time. BASIS or system admin should install the SAP notes however, Fiori Consultant should be able to find and advise the right SAP notes to be installed.

Lesson Learned 3 – Sizing Implications

Another point to consider is sizing the required infrastructure. It is essential to understand the intended target audience using the app and what is the target user base and what is the expectation of usage within the corporate network vs access from external? Please search on SCN about sizing of the SAP NetWeaver Gateway.

Lesson Learned 4 – Security

As mentioned earlier Security is one of the key concerns. Most companies have strict policies and could already have their own MDM solution in place. Common MDM tools could be BES 12 or they can use Cisco VPN or Microsoft Unified Access tools as the only option.

While some companies are happy to expose SAP Fiori to the internet via reverse proxies, security driven and regulated industries need an additional layer of security, e.g. via a native wrapper application or a secure browser. SAP Mobility and Fiori roadmap is continuously evolving with interesting developments in the MAM, MCM space, so it is always advised to check with the client first on their security needs.

In our case the client already had a SAP NetWeaver Portal for SSO and we needed to integrate SAP Fiori with the portal. But the SAP Portal did not target smartphones and tablets so we had to look at options Mobile Edition of SAP NetWeaver Portal.

SAP MDM solution Afaria could be useful to deploy a native wrapper or secure browser but if a client already has their own MDM solution it is almost not possible to replace it with something new.Depending upon your client security requirements there are a couple of options that can be recommended.

Depending upon your client security requirements there are a couple of options that can be recommended to authenticate the user

• User name and password
• 509 client certificates
• SAML tokens generated by SAP IdP or another SAML Identity Provider
• SSO2 tokens generated by an SAP NetWeaver Portal instance
• Other single-sign on providers

Lesson Learned 5 – System Landscape and Transportation

Ideally there are customising requests and workbench requests in 2 system landscapes that need to be transported in synch between the SAP Gateway server and backend systems. Some companies use Quality Gate Management (QGM). With the help of QGM the workbench and customising requests can be transported in synch and the process can be controlled and monitored centrally from SAP Solution Manager.

In a typical Fiori Implementation project that requires creation of new OData service too, following 9 steps should be followed

Step 1 – Create a change

Step 2 – Create workbench requests and customising request

Step 3 – Gateway Service Builder – OData Service Creation (only applicable if a new OData service is created)

Step 4 – Gateway Service Builder – OData Service Implementation

Step 5 – Gateway Backend – Service Registration

Step 6 – Maintain Service – Service Activation on SAP Gateway Server

Step 7 – Maintain Service – System Alias Customizing

Step 8 – SAPUI5 Application Development

Step 9 – Transport changes via QGM