Beginning With An MI Project

Beginning with an MI Project
Applies to:
Mobile Infrastructure 7.0, Mobile Assessment Management 3.0 and Mobile Assessment for Utilities 3.0. For more information, visit the Mobile homepage.
Summary
The main purpose of this article is to explain all the concepts, attention points and considerations of a Mobile Infrastructure project focus on the technical side of it based on my first experience implementing Mobile Assessment Management and Mobile Assessment for Utilities. Author: Alvaro M. Guzmn A.
Company: SAP Multi Country Latin America MCLA Created on: September 13th 2009
Author Bio
I'm Alvaro Guzmn and Ive been working in SAP LA since 2007 as a CRM consultant. My mayor skills are focused in web development areas like CRM IC, CRM Web UI, UCES, BSP, WS and Java Web components.
SAP COMMUNITY NETWORK 2009 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 1
Table of Contents
Beginning with an MI project ......................................................................................................................... 3 Related Content ............................................................................................................................................ 6 Copyright ...................................................................................................................................................... 7
Beginning with an MI project

A few months ago I had the opportunity to participate in my first Mobile project and I decided to share with you my experiences. To start I must confess that I am a Java/ABAP web developer with no formal training on Mobile Infrastructure solutions but even though our project finished with a happy ending. In this particular case I participated as a developer for Mobile Assessment Management (MAM) and Mobile Assessment Management for Utilities (MAU) implementations and that is the reason why this paper will be focused on the technical part of them. But what do we know about these two? At a glance, both applications help the technicians of a maintenance/service company to retrieve and display work orders and tasks in a PDA. They provide all the necessary information for technicians to work completely offline, which improves their work efficiency since they dont need to communicate with the center of operations at all. Here you can see a self explaining graphic of a standard process:
If you translate this figure into common day activities it would be something like this: At the beginning of the day the backend server creates and assigns the corresponding work orders to the available work teams. Those teams synchronize their PDAs in the morning and proceed to go out to the field to do their jobs. During the day, the technician goes to the indicated places in order to complete the orders they have in their devices and finally, at the end of the day, they synchronize again their PDAs in order to send all the data collected to the backend system closing the process. Below is a print screen of the standard solution for MAU, which runs in the PDA and was the canvas for our enhancements:
Having gotten a brief idea of the MAM and MAU applications, we can start talking about the project. The beginning of the realization phase was really hard for us mainly because of the lack of technical experience not only within our team but in the region, which adds that extra bit of pressure who nobody wants. Besides this, I have to tell you that it was a great experience and an excellent beginning for me in this kind of applications: First of all, because of the outstanding team that I worked with and second because of
the satisfaction of seeing my work in a PDA in the middle of street, and being used by the technicians who finally can tell you whether your effort was really worth. I can start sharing my technical thoughts by saying that in addition to the coding, which is kind of straight forward once you got the idea of the communication objects used to send/receive data from the server (known as SyncBOs) and their handlers, you have to be aware all the time that your target should be a small piece of hardware with very limited resources. I can hear you saying: Of course, everybody knows that, but believe me, that is nothing compared with the experience of running the application the first time in the PDA with the data that is supposed to be used on the field day by day it took forever to synchronize it! Now is a good moment to explain that the synchronization is nothing more that the process where all the data is sent to the PDA from the server and vice versa. But no worries, eventually we solved the problem (keep on reading and find out how!). About the PDAs: They are like children (if you allow me the comparison) who cannot handle much weight and do not have the reasoning necessary to deal with tough problems. What is that supposed to mean? Technically speaking we have less than 100 Mbs of RAM, a 625 Mhz processor and a JVM compatible with Java version 1.1 sounds like fun isnt? Deeply, both MAM and MAU are Web Applications that are deployed in a Servlet container installed in the PDA and they run in a Web Browser. For those of you who knew something about mobile applications platforms design and style, you can immediately notice that this is not the best approach because we have a web server running in the device that is actually responding to requests from just one client: The server itself. I must say that after having been struggling with this implementation for a while we heard something about an AWT (Abstract Window Toolkit) solution which sounds more logical for this kind of implementation since it is just a Java stand alone application which can run faster and do not need to use a web container. Unfortunately we were in the middle of realization phase so it was kind of late for the change (no regrets so far). If you take a look at this graphic of the architecture of a Mobile solution youll see my point about the current approach:
As you can see, in each device we have the SAP MI Client installed which in this case is comprised by a Servlet container (Tomcat), local database (DB2) and the administration web application: Yes, that is the standard approach. Nonetheless, no matter the adversities or failures, we continued our jobs and finally our developments started to work as expected: A couple of standard views updated at the beginning, a few another new ones created and finally but not least, a couple of Web Services executed and our own SyncBOs used. Not bad isnt?
After developing the Clients requirements we faced another problem: the excessive response time in the synchronization. This process is the central part of the communication, so we focused on improving our developments and the configuration by performing the following activities, which in the end reduced the synchronization time by half: - Disabling a couple of SyncBOs that helped us to reduce the time of the synchronization process by sending only the information that we need - The use of the Distributor program, which is a standard GUI transaction that runs in the MI Server every day and performs some data processing to make it available just before the actual synchronization takes place - We installed on each device an Add-on for the Tomcat that disables this web servers functionality that keeps constantly looking for changes in the JSP files and performs the corresponding deployment of the objects - Reduced the memory consumption in our Java developments After performing all these changes and generating and deploying a bunch of war files (I mean A LOT!), we were ready to deliver a solution which met the Clients expectations with reasonable response times and functionalities that a couple of months ago seem to be far away or unachievable. But now we have gained extensive knowledge and experience (without any dependency or weakness), which for me and the team is a huge success and something to be proud of. To finish this article and for those who want to enjoy the experience of the Mobile technology I just have one phrase for you: Believe in the project, believe in the team and please above all test directly in the PDA from the beginning!
Related Content
For more information, visit the Mobile homepage.
Copyright
Copyright 2009 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Serv er, PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries. Oracle is a registered trademark of Oracle Corporation. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc. HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. Java is a registered trademark of Sun Microsystems, Inc. JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this docume nt serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable fo r errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituti ng an additional warranty.

Beginning With An MI Project

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Beginning With An MI Project

Uploaded by

Copyright:

Available Formats

Beginning with an MI Project

SAP COMMUNITY NETWORK 2009 SAP AG

SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com 1