Mobility in Transportation Management

Former Member · ‎01-28-2013

This blog is cross posted from pascalrenet.com

I recently started looking into the possibilities of integrating a smart mobile device with the SAP Transportation Management software. As far as I know SAP has a couple of offerings (one running on Android and another running on IOS) in that space, both requiring NetWeaver Gateway as well as the SAP Sybase Unwired Platform. This seemed an unwanted overhead for someone that just wanted to get a presentable proof of concept app off the ground and so ventured in other directions.

This post will attempt to summarise my thought process and present what I was able to clobber together.

Firstly I tried to brainstorm some of the characteristics that this app had to have - in no particular order.

Criteria	Characteristic
Usability	The intended audience of this app are the drivers, their job is to drive not understand how an app works. The app therefore has to be intuitive and super simple to use.
UX Design	Using this app must complement the driver's day to day tasks and activities, not hinder them. Delivering a user engaging interface that places information where it is supposed to be in a layout that is adapted to the mobile device is part of that experience.
Device agnostic	In this BYOD era, applicable to both employers and sub contractors, you cannot afford to develop for only one platform or device. It was therefore important to keep a develop once - deploy to many attitude. Using a framework such as phonegap can help in that respect. Based on that the choice was naturally to go down the path of HTML5, rather than native development.
Limit data exchange	In the interest of time and money, limit the amount of data exchanged between the device and the server (use of manifest payload on device, AJAX update).
Local storage capable	In vast areas such as Australia, you are bound to sometimes be in a location where you have no mobile network coverage. It is therefore important to be able to report an event when it occurs, store it on the device and sync it with your backend system when coverage is restored.
Multiple event type support	We have setup several event types within our EM environment (Depart, Pass, Arrive, Load start/finish, unload start/finish, ETA/ETD update, Delay, etc...). I should be able to report any one of them. Some may be specific to a planned event (i.e Arrive at location X), some may not be (i.e Delay due to heavy traffic)
Zero paper based	In an effort to be environmentally aware, reduce where possible, the amount of paperwork the driver has to carry with him. This means delivering on the device all the information the driver needs (planned times, expected pick and delivery locations, cargo items, consignees, etc...)
Safety	Send the driver special warnings when carrying dangerous goods, access to special safety checks documentation.
Efficiency	Receive the information in near real time and avoid subsequent double entry.
Integration	This app should as much as possible integrate in our current infrastructure.
Time zone support	We operate is several time zones - the teams must be able to operate and analyse information in their respective time zones, not in UTC timezone.

Now that I had a rough idea of where I was going, I started looking at the integration possibilities. This meant identifying what was available in SAP standard first as this was going to drive how I could integrate with it (should I go via PO, should I hit TM directly....). I was quite enthused to find that EM had all that I needed to get this proof of concept of the ground and pave the way for this then becoming a basis for a productive solution.

The technicals

EM has all the BAPI's I need (both to extract the information I need as well as update events in EM). The great thing with BAPI's is that I can either invoke them directly with an RFC connector, or I can expose them as web services. For this proof of concept I went with the former - an RFC connector and I used php as the programming language to invoke it. So at the end of the day my setup looked as shown below.

SAP TM is of course used to create the freight orders and the associated objects and this information is then replicated in SAP EM. The process was going to be:

The Mobile device makes a request to retrieve a list of tours,
The request is sent to a web server that invokes an SAP EM BAPI,
SAP EM sends a response to the web server which translates the response in a JSON feed,
The mobile device consumes the response and presents the data to the user.

Easy!

The picture below shows graphically the various screens of the app (which is still work in progress).

Technically this is how things play out.

The app is launched (I have not for the moment implemented a user logon) and the first screen asks you what tours you want to retrieve. You indicate a start and finish locations as well as the id of the resource you are driving on that given day. The search could also be based on driver name (as we assign drivers to freight orders) or the prime mover registration number.
Once the search button is pressed the search parameters are sent to the web server where they are then wrapped in a RFC request made to the EM server. The BAPI that is invoked is /SAPTRX/BAPI_EH_GET_DATA. This BAPI is great because you can decide the number of internal tables that you want it to return. For this first request I only want to retrieve basic information (freight order number as well as start and finish locations). If the query is successful it will send a response to the web server with list of applicable tours.
The web server receives the response and translates it to a JSON feed and is then consumed by some javascript code present on the device and outputs the data in a listview - I have used Jquery Mobile here for this.
The driver can scroll through the list and select a job by tapping on it. Doing so once again fires a request to EM, using the same mechanism, invoking the same BAPI albeit this time using different parameters (the freight order number) and also requesting more data to be returned (e.g. event information).
This time more detailed information, just for that tour is output. Again we have a listview where each line represents an expected tour event. The driver simply has to tap the icon corresponding to the event he wants to report. Doing so, this time, invokes the BAPI /SAPTRX/BAPI_EH_ADDEVENTMSG_02 (though I have not tried it, you could also use the BAPI /SAPTRX/IDOC_INPUT_EVMSTA if IDOCs was how you wanted to go). To limit the amount of data exchanged, this update request is made using AJAX. If successful, the event information on the device is updated : The status now shows as 'executed' and the actual times are now also shown.

The design

My usual method of working is to first worry about how the technical pieces are going to hang together and then about the design. In this case I started with Jquery Mobile, which out of the box already offers an visually pleasing interface design, that can be tweaked to your liking. That is what I did - below is a picture of the app running on an Ipad.

That's it! All up including the design, this took just a little over a day to do - and that is what I wanted - to quickly come up with a working demo.

There are still a few more bells and whistles that I want to implement though.

Multiple event reporting

As indicated above, you want this app to report all possible events, but how do you do enable this without having so many buttons that it makes your app look like a christmas tree! One of the things I am working on is the introduction of a slide in (and out) panel, for each event, that allows you to report any (un)expected event.

As shown above, tapping an event reveals a drawer like panel that allows you to report events such as unload start/finish, load start/finish, delay and depart or arrive.

Time confirmation

Up till now I took the stance that the driver would report the event at the time it happened (or close enough for it not to be an issue). However there are always unexpected things that do not always make this workable, the driver should therefore be able to override the reported event time. Therefore a new popup will ask for confirmation before posting the event time back to the backend.

That's it for now. I'd be very interested to hear from others what they are doing in that space.