Mobile Computing is getting more and more integrated into our daily lives. In the last 10 years users went through tiny laptops up to netbooks and tablets, from common mobile phones up to smartphones and now we've finally arrived at the age of the so-called "Wearable Devices". It doesn't matter if you're wearing a Smartband, a Smartwatch or even Google's highlight product the Glass - With all those little devices you can do nearly everything what you could do with an ordinary computer. That means that you could call your friends or text them a small message or e-mail. You could go to the internet and search for the current cinema program or whatever you're looking for. It's also possible to monitor diverse physical functions, to take videos and pictures or to let you navigate through an unknown city all by just looking through a small monitor fixed on eyeglasses for example. Actually those features are quite cool for conventional home users but what if you're a business user and want to take advantage of them in your company? This is exactly the question with which businesses are struggling at the moment and also what I'm trying to answer you in this blog post.
My name is Stefan Heitzer and I'm a developer who works for the SAP consulting company T.CON GmbH & Co. KG in Plattling (Germany). We are always interested in new technologies and in things that can improve the user experience and the look and feel of applications. Due to this reason I dealt with scenarios for wearable computing in the field of ERP-Systems for my bachelor thesis. So we soon bought a Google Glass for our company and started with the first attempts of developing applications for the Glass which finally resulted in an app for mobile maintenance in connection with the SAP Netweaver Gateway. Our company has already developed the so-called “Mobile Maintenance Management” for Android phones. The app mainly helps technicians to overview and design the maintenance and repair proccesses much more efficient. For more information please check out the following link: Mobile Maintenance - T.CON Team Consulting. But let's start from the beginning. What I want to show you in this post consists out of the following points:
- The general functionalities of the so-called „Mobile Maintenance Management Glass“
- How to consume oData with the Glass
- How to make pictures and videos with the Glass and send them to a SAP Backend
The General functionalities of the so-called “Mobile Maintenance Management Glass”
The app itself has two main menu items. It’s possible to review the current inspection and repair orders and to create confirmations for them. The other action is to generate new notifications for machine damages. As it’s the normal way of using the Glass you’re able to start the actions either by voice or by tapping and swiping through a normal menu. (For creating an uniform experience I decided to display all attached images in the way how it looks by tapping and swiping)
The above picture shows you the main menu / start menu with the options you have. Let's have a look at the first option.
Via "Show orders" the User is able to get an overview of all the current inspection and repair orders. This means that the first step is to establish a connection with the SAP Backend and retreive all the orders. The process looks like the following:
Each order can have one or more so-called "Suborders". The user should be able to explore each suborder and should be able to make full or partially confirmations for them due to the fact that he's wearing the Glass in his company and can fix the problem live. The confirmation itself can consist out of a confirmation text and also needs to have a valid time in minutes which was needed to fix the problem. All the required information can therefore entered by voice. To make sure that only valid values for the time can be entered, the app checks the corresponding voice input for a number. The menu for this process and the validator is been shown in the next screenshots
As already mentioned the user can make a partial or a full confirmation. The partial one should be made if technican has something done for fixing the problem. A full confirmation should only be done if the error is completly solved. When all the required information have been entered the following actions look like the following:
It doesn't matter which kind of confirmation the user makes. Always when this process is executed the app makes a connection to the SAP Netweaver Gateway and creates it with the entered information. For taking knowledge that there have already been made some partial confirmations for a suborder, each order has a small icon (circle) on the left corner. Red means that the erros hasn't been solved yet and yellow that there has already been made a partial confirmation.
A possible scenario can also be that the technican is on the shop floor and suddenly a problem appears. For this reason the second menu point "Create notification" exists. As well as "Show orders" the first step is to establish an connection to the SAP backend. Each notification has a specific damage code and of course a priority. Those information are going to be fetched at the beginning. The notification itself refers always to a functional location or to a equipment. This code can either be known by the technician or it can be found as a barcode on a maschine for example. So for entering it there are generally two possibilities: Either by voice or by scanning a barcode with the built-in camera of the Glass. While the codes are scanned or entered by voice it's of course possible that some errors can occur. Therefore all entered values are checked as well as it happens with the input in the "Create confirmation" process.The complete order of events looks like the following:
At the beginning of describing the second function I said that it's also important to enter a damage code and the priority of the fault notification. For a better user experience we designed a list consisting out of those elements. By swipping you can browse through the elements and via a simple tap you make your choice:
After choosing the damage code, the priority and entering a valid code for a functional location / equipment the user reached the point where he's able to create the notification. But there can be more information and things be entered. For example the user is able to set a text, to make a picture or to record a video. All those information are transported later on to the SAP Backend:
Now let's go on with the coding. In the next step I'm going to show you some relevant coding points which need to done for making the app work.
How to consume oData with the Glass
The app itself is an Android development project. This means that we coded with plain Java. Due to the fact that we consume data from a SAP Backend we had to look for a way how to connect with it and the best choice was to use the SAP Netweaver Gateway. The Gateway provides the data in the so-called oData format. For this reason it was necessary to create the corresponding entities and also the classes in the frontend. Let's have a look at the the entity for confirmations and at the entity for orders:
As you can see this are normal entities which can be created with the Netweaver Gateway. In the background we have coding for the needed CRUD-Operations. For the orders for example exists a GET_ENTITYSET-Method which is responsible for retrieving all the stored orders in the system and the redefined method for the confirmation is a simple CREATE-Method. When we would call the GET_ENTITYSET-Method in the browser we receive all the relevant data in the oData format. So we need to find a way to handle this format in our Java coding. Therefore we use odata4j. odata4j provides a toolkit with which we can build a complete consumer of oData inside our Android App. With this framework we create at first a new ODataConsumer. The builder for this consumer needs the URL which should be called. In many cases the services need a basic authentication so we also have to set a new so-called "ClientBehavior" ("BasicAuthenticationBehavior") which accepts a username and a password. In the following coding you'll see that we also have an instance of "SAPCSRFBehavior". This instance is needed due to the Cross-Site Request Forgery Protection. The SAP Netweaver Gateway is actually using for each modifying request like an insert, update or delete a so-called "CSRF-Token". This token needs to be included into an HTTP-Request because the gateway is checking for each request the validity of the token. If the validation fails you'll get an error 403. We do not want to get this kind of error so we have this class which tries to fetch the token while sending a normal GET-Request. After setting this "ClientBehavior" we actually haven't made the request yet. To finally execute the service call we have to choose the entityset which we want to receive and call the method "execute()". The whole coding for this looks like the following:
As you can see we're looping over the found orders and for each order we create a new one and get the corresponding properties via methods of the class "OEntity". Afterwards we're able to store all found orders in for example an ArrayList and go on with displaying them.
Also the creation of a confirmation is no magic. Here we just have to call another method of our ODataConsumer:
With the method "createEntity" we're able to say for which entityset we want to send the POST request. Afterwards we only have to set the properties and give them the right values. Actually all requests are handled in this way.
There is only one special thing. As I meantioned in the first point the user should be able to make pictures and also record a video for a notification. Here we have to do some special coding which I'm going to show you in the next section!
How to make pictures and videos with the Glass and send them to a SAP Backend
The process of taking the picture and sending it to the backend is just a bit easier than the video part so let's start with the picture. The Glass itself has a built-in camera which we use for this procedure. So actually the first thing what we have to do is to start with the shooting of the picture. Therefor we're using the following code:
With the new instance of the "Intent" we can start the picture process. What we receive in the method "startActivityForResult" is - if it was successful - the path of the currently made picture. With this path we can create a new file. Afterwards we only have to check whether the picture really exists. Actually the best way to send the picture to the system is to convert it into a BASE64-String:
The entityset for making a notification consists out of a property for the picture. This attribute get's the converted BASE64-String as a value. Afterwards the request is simply executed via the "createEntity" method.
A picture is for transporting in one request ok but there's going to be a problem with the video because it's way to huge for one single request. If you try to convert the video into a BASE64-String you would result in an OutOfMemory-Exception. Each Android application has a specific amount of memory which can be used for transactions, processing etc. Converting the video into the mentioned string or sending it in one single request is just way to much action for the app and so this leads to the named exception. In order to counteract this phenomenon we created a loop which creates blocks of 1024 bytes and converts this blocks step by step into the BASE64-String. Afterwards you can put the complete string together and the conversion is finished. The corresponding code looks like the following:
Now we made it to solve the OutOfMemory-Exception while converting the image but as already said the same problem can occur when the request is executed. Therefore we're using a streaming mechanism. This means that we've created a function which includes a recursion. The BASE64-String is again separated into blocks of 2000000 bytes and afterwards each block is transported and the function calls itself again until the whole request is finished:
The entityset which is called at the request here has a special attribute called "Flag". This flag is used for recognizing whether the request is finally finished or not. If the request shouldn't be at the end the transported BASE64-String is added to the already received string which is stored in a database table. The coding for the whole procedure looks like the following:
This was the last coding snippet which I wanted to show you so we've actually reached the end of this blog post. If you need further information about MMM, the Glass development or SAP Netweaver Gateway check out the following links:
- Mobile Maintenance - T.CON Team Consulting
- Google Developers
- odata4j - An OData Toolkit for Java - Google Project Hosting
- SAP NetWeaver Gateway 2.0 – SAP Help Portal Page
I really hope you enjoyed reading my new blog post and if you have additional questions don't hesitate to contact me!
Kind regards
Stefan
- SAP Managed Tags:
