FIORI Implementation Simplified, Part 3

[former_member236489]

This is 3rd blog in the series "FIORI Implementation Simplified".

In part 1 we discussed landscape and usability of standard apps and in part 2 we talked about development environment.  Part 2 can be accessed by clicking here and Part 1 by clicking here.

FIORI Development

Now that you have an environment setup, with all the tools and skills available, how do you go about implementing and, if required, doing custom development for an App.

1. First things first, most of the apps will need configuration to work out of the box and there really is not much documentation on it. So read whatever documentation you can lay your hands on and find out where in IMG you will do configuration. Very few apps will work without doing configuration, though Product look up and count stock apps almost always work without any groundwork.


2. Second, standard apps are based on best business practices developed by SAP. If the processes have been modified in ECC then custom development will be required to make even standard apps work.


3. Third, standard apps have lots of extras, which may not be required. Rather than working on removing those features, I recommend to develop a brand new app.


4. Fourth, developing apps is an iterative process, users may not be able to visualize what they are asking or getting. Be prepared for a very effective change control process to control the timeline/resource creep.

If you end up deciding that development is required, keep following points in mind...

1. FIORI UI, which is Java script/Jquery based, gets the data from ECC environment


2. Interface used is called Odata, which at the very basic is ABAP code and structures etc. for us. Odata is published as a service and is managed using txn SEGW in ECC.


3. Any data that you want to see in the UI or send through UI, must be part of the Odata.


4. Browser and App UI WILL behave differently, so make sure to show and test the UI in all the environments.


5. For our developments, we almost always extended the standard odata and then made changes to it.

For more technical details refer to my blog about Product Look Up app. This is one of the easiest apps to work with and will work out of box without any configuration. I will keep adding more details as I publish blogs on other apps we developed.

Based on all the app development we have done, it is best to show users a standard app first, it helps them visualize (somewhat) and can be a starting point for you.

Custom Client

This step is really optional and only required if you want to get real fancy and want to use FIORI to its fullest extent.

If you do that, welcome to the world of integration with off the shelf scanners. Idea is to be able to scan a barcode, which can be a product or a document. SAP does provide a built-in camera scanner, but it is finicky and works exactly like a camera i.e. without proper lighting you won’t be able to scan a barcode. If you get a chance, go to your local Target store. Have them scan a barcode with their handheld device; it is quite a ballet and you will get the idea why it may not be a very good idea to use device's built-in camera for scanning.

So if you want to integrate a scanner, you will have to rebuild the app with a plugin. What that means is

1. For iOS environment, you will be have to republish the modified app using X-code. For iOS you will need access to a McIntosh and X-code development environment.


2. For Android you will need access to Android SDK. Android SDK is comparatively an easy environment to work with.

For our implementations we had Honeywell hardware with Captuvo Codova and KASPEL plug-in.



There are many blogs which talk about Cordova and KASPEL plug-in, which can give you more details.

We also Integrated with a regular handheld scanner, which was not hard, but just tricky because these handheld scanners have an inbuilt "enter" or "tab" key after barcode is scanned in.



Publishing custom client

If you have a custom build client, you will need to publish it to all the mobile devices. There are two ways to publish a client,

1. First, If you have physical access to all the devices or can bring in all the devices to IT staff, then you can just publish the app one by one on each device, but somehow I think that will not be acceptable in most of the situations and that's where second option comes in play.


2. Second option is to distribute the custom client/app remotely and that’s where services like AIRWATCH comes in. Ask your IT support staff, they can help you out with it. If this is the first app you are planning to use on mobile, that you will need to consult separately on setting up mobile infrastructure.

Out next and last blog in this series will discuss security, a sample project plan and timeline to g...