For the best experience, try the new Microsoft Edge browser recommended by Microsoft (version 87 or above) or switch to another browser � Google Chrome / Firefox / Safari

Enterprise Mobility Platform Technical Discourse

Xoriant Enterprise Mobility Platform Technical Discourse

Table of Content


Xoriant Enterprise Mobility Platform (XEMP) enables a typical enterprise to significantly enhance the mobility of their traditional applications on multiple mobile devices. IT managers can deploy mobile applications with minimal change to the current structure of the applications, while maintaining the traditional criteria such as security, data integrity, reliability and availability. By using industry standard open source technologies extensively, while retaining flexibility, we designed XEMP to work with various applications in multiple industries and on a multitude of mobile devices.


The time for enterprise mobility is now. According to IDC, by 2013, more than 1.19 billion workers worldwide will be using mobile technology, accounting for 34.9% of the workforce.* The impact of mobility on business is clear. In increasing numbers, business users are expected to handle critical tasks and decision making in real-time, no matter where they are.

An organization that provides field service support is expected to have real time visibility into inventory positions, enabling it to accept new orders on the fly with real time updates from the field. These efficient operations are quickly becoming the de facto way to do business in order to optimize not only internal business processes, but also external customer facing operations.

The proliferation of network connectivity, open standards and portable devices has made all of this possible. By adopting mobility, enterprises today are revolutionizing the supply chain—from inventory, asset tracking to field operations like scheduling, delivery and navigation. In case of financial services companies, it is becoming essential that at least some critical information and some transactions are available on the mobile devices, whether the users are the internal traders or the customers.


Organizations have spent the last few years selecting best of breed software and applications to streamline their business processes and their decision support systems. These have ranged from Enterprise Resource Planning (ERP) systems to custom applications and business intelligence environments. A lot of effort has also been spent to integrate various applications that often have different data formats and semantic differences.

Organizations have come to realize that the next step in the evolution of their business processes is to mobilize key business processes that will provide both internal and external interactions via mobile devices. These mobile devices are not just mobile phones, and include tablet devices and any future devices that can communicate with the existing applications.

In order to move towards a mobilized world, organizations will have to grapple with several issues:

  • Isolate Systems/Data and Abstract Business Processes

    Every organization has different departments that have their own processes, applications and data. It is important to be able to isolate the processes from each other, so that changes in the department specific processes do not affect the whole organization. This can be enabled only if a common service layer is defined for all the business processes that provides a generic interface and an abstraction layer to integrate with every individual process. Any mobility solution needs to present an approach, where any business process that you wish to mobilize is understood first and the interfaces are defined with a clear abstraction. The service layers thus developed in this fashion will enable external devices and applications to integrate safely, and any internal change will not affect or break the integration. The other key advantage of this approach is that only the minimum required functionality is exposed to outside applications to be able to integrate into a specific business process. Abstraction and isolation are two cornerstones of good design and allow wider usability of the enterprise applications in the midst of changing business requirements which minimally affect the overall integration.

  • Security and Access Management

    Data security is of paramount importance in the overall scheme of any mobile solution—security like authentication, authorization and data encryption are mandatory. It is important for the solution to clearly provide for authorized access not only to different applications but also at a more granular level i.e. data within an application. For example, a field service personnel will use a mobile application in the field to complete the service orders assigned to her. She will be able to access and modify service order data and inventory positions for only her order entry. No other data that is not required is visible to her.

  • Integration

    No application can exist in isolation—organizational systems are not only inter-connected but also integrate through data. As data flows from one system to another to help complete business processes, data integrity and validation becomes critical to business compliancy. As a result, the solution should be able to present mechanisms that allow standards-based integration and adapters to enterprise resource systems like SAP, Oracle and even custom applications through standard and open integration mechanisms like XML.

  • Scalability

    The number of mobile devices is increasingly daily and organizations have come to accept that with time, an increasing number of their existing processes will have to be available on mobile devices. The mobility solution should be scalable to cater to increasing devices and functionality that will need to be made available over time.

  • Multiple Mobile Device Support

    Mobile devices come in different functionality, capability, form factor and types. And it is not just about a mobile phone anymore—there are tablets and various other connected devices that will need to integrate into the solution. All popular mobile device OS’ should be supported. The mobility solution should be able to allow access or integration by various mobile devices via an Open Standards Service Layer. This Service Layer should be ideally written once to cater to multiple applications from multiple devices.

  • Infrastructure Services

    Organizations need to focus on their business functionality rather than infrastructure services in any solution. The mobility solution should be able to provide various infrastructure services like Scheduling Engine, Notification Engine, Integration Adapters, Account and Access Management, among others.


Xoriant Enterprise Mobility Platform (XEMP) has been conceived, designed and implemented by Xoriant teams through our multiple engagements mobilizing existing enterprise applications of our enterprise customers in multiple industries including Financial Services, Manufacturing, Logistics, High Tech and Consumer Products, for their mobile users – both internal as well as external. XEMP addresses all the common issues raised above and significantly accelerates the mobility capabilities of existing enterprise applications with minimal changes to them.

The XEMP consists of two distinct components:

  1. Xoriant Mobility Server (XMS): XMS abstracts the business processes and data elements of the underlying enterprise applications to be mobilized, and interacts with the mobile devices through Xoriant Mobile Apps Accelerator.

  2. Xoriant Smartphone Apps Accelerator (XSAA): XSAA significantly cuts down the time and risks in developing multi-smartphone mobile applications, while preserving the nuances of capabilities and usability of individual smartphones. XSAA can be used independently for non-enterprise pure mobile applications, while it can be used in conjunction with XMS for mobilizing enterprise applications.


The Xoriant Mobility Server (XMS) is our solution to enabling mobility in an organization for any business process, which can be represented in one or more applications. To understand what comprises the XMS, it is important to break it down into 3 Key Areas:

Mobilization Approach

We strongly believe that the first step is to understand the business process that needs to be mobilized. This involves typically the following steps:

  1. Understand the existing implementation and the different data sources that need to be accessed and written into.

  2. Design a domain model that captures the business process. The development of this domain model is critical to isolate the real business process and provide a standard layer on top of it, to allow different devices to connect to it in a seamless way without knowing about the internal implementation.

  3. Identify how data will be pulled out from the backend system i.e. use custom adapters and/or schedule the data extraction into the domain model.

  4. Design and develop different services that expose the domain model and
    business process.

  5. Develop thin standards-based REST layer that wraps these services and which will be used by the mobile applications. Note that all mobile applications will go through this layer.

  6. Utilize the Xoriant Smartphone Apps Accelerator to build various mobile clients. The Xoriant Smartphone Apps Accelerator comprises building blocks on various mobile platforms that provide well tested modules to help build high quality Smart Phone applications much faster than traditional development approaches.

XMS – Server Component

The Xoriant Mobility Server is a standards based server that helps mobilize an existing enterprise application.

A high level architecture diagram for XMS is shown below:

The XMS (shown in blue) based on its High Level Architecture diagram can be broken down into the following components:

  1. Domain Model: As mentioned in the earlier section, a complete analysis of your existing business process is done to understand the data and operations that will be needed as part of your mobility application. This data and operations are then defined into a domain model, which will be the driving force behind your mobile applications. Your mobile applications will need to interact and work with only this domain model. They do not need to work directly with your main data source. This abstraction is key to allowing you to change your business processes without affecting the domain model.

  2. Standards based Service Layer: The fundamental architectural approach that we propose is to define the API or Service Layer as a first step. This service layer is what the mobile applications will work against currently and in the future. Any changes in this Service Layer directly affect the existing mobile applications and thus, it has to be designed carefully. As you add new functionality into your domain model, you can simply extend your Service Layer so that newer mobile applications or functionality can take advantage of that. We believe that an API first approach will help insulate your offering and protect your investment in key business processes as newer mobile platforms and devices emerge. The Service Layer is based on Open Internet standards like HTTP and REST and primarily makes use of either JSON/XML formatted request and responses.

  3. XMS Infrastructure Components: The XMS comprises of several infrastructural components that take care of the critical operational components, which take care of the heavy lifting and thereby help you focus on your business functionality. Based on our experience and best practices for enterprise applications and integration mechanisms, we have identified and provided several modules that help you mobilize your existing applications. A block diagram depicting the key modules inside of XMS are shown below:

Description of XMS Infrastructure Components:

Service Layer and Domain Model: This layer comprises the REST based services layer that is the primary software contract against which mobile applications will be written. There is a seamless mechanism by which new services in the future can be introduced and made available to devices. The Domain Model captures the essence of your business processes and contains both data and operations that are exposed by the Service Layer.

Administration: XMS provides a complete user authentication and authorization module. This will help you define users and what operations they are authorized to do.
Device Tracking & Licensing: XMS contains support for provisioning devices, so that only the authorized devices have access to the functionality. You can also limit the number of devices that can be used in the system.

Job Scheduler: A scheduling engine is a key part of any integration. Master and transactional data that need to be moved from the XMS and into various other systems need not be done in a synchronous fashion, but the data movement can be scheduled at different times, defined by the user. This helps manage the system load and also to keep the transactions and data into a staging area for verification before they can be applied to the production system.

Backend Adapter: XMS comes with ready to use adapters for various Enterprise Resource Planning (ERP) systems like SAP, Oracle and Infor LN. It also provides adapters for other integration mechanisms like Message Bus, File Based Systems, etc. The standard adapter framework can be customized for any package or custom system, based on the individual specifications.

Multi-Tenant and System Services: XMS fully supports multi-tenancy and can support various partitions of your data by customer, organization and any other category. It also has various system services like Logging, Transaction Resolution, etc.

Notification Service: XMS contains full support for System and Business Events. You can define them in XMS, to whom the notifications need to be delivered (recipients) and the medium (Email, SMS, Web) via which they have to be delivered. Examples of Notification Service could be an incoming report, inventory low alert, unauthorized access and many more.

XMS is currently implemented in Java-based Open Source technologies such as Hibernate, Quartz and Tomcat and thoroughly tested in several domains. Xoriant teams have the ability to not only implement the XMS modules in a customer environment, but also replace some or all the components according to the customer’s own IT standards and implement similar functionality in much quicker manner. Since the current modules are implemented in a very flexible and modular fashion, replacing the underlying technologies with those meeting the customer standards significantly reduces the time and risks involved.


As organizations move on the path to mobilizing their application, the decision to choose a mobile platform is not an easy one. There are several mobile vendors and each mobile phone differentiates itself via usability, features and price points. Depending on your decision, you could choose from iPhone, Android, BlackBerry, Nokia and Windows Mobile in the Smart Phone category. Writing applications for each of these platforms is time consuming and requires different skills since each of the application toolsets come with their own language, tools and supporting components.

To address this fragmented smartphone environment, we have introduced the Xoriant Smartphone Apps Accelerator (XSAA). XSAA is a set of libraries, which help in speeding the application development on various Smartphone platforms. Using the accelerator libraries, any application features can be incorporated in 20-50% less time than what it would take to develop from scratch. Additionally since some of the underlying foundation has already been tested, the application quality is also significantly higher. The Xoriant Smartphone Apps Accelerator libraries are available for iPhone, Android, Nokia – QT, BlackBerry and Windows Mobile.

The diagram below shows the Smart Phone building blocks that are currently present:

The following section describes these building blocks and their functionality:

Application Configuration: This building block manages all application settings. It supports the XML format and properties file format for storing application wide settings.

Location Based Services: This building block abstracts the GPS module integration on the device via a API. The API abstracts the inner working of the GPS and provides relevant information to the application. Google Maps Widget is also included in this block to help developing location applications that require integration with a map.

UI Widgets: This is a set of common widgets for an application. Initial set of widgets include List, Details and a Photo Browser.

Social Media Integration: This is a framework that integrates with popular Social Networking sites like Facebook, Twitter, MySpace, etc. This building block allows operations like getting friend feeds, posting a news item, tweet and various other operations.

File/Database Management: Any mobile application running on a device will need to persist information across application starts. This persistence layer could be either File or Database driven. This building blocks provides abstraction for the file and database operations on the device.

Audio/Video: This building block provides an abstraction for Audio and Video functionality of
the device.

Utilities: The initial set of utilities includes XML Parser, Date/Time and Encoding/Decoding
data support.

Auto Update: All native mobile applications need to be updated. The Auto-Update functionality will enable a mobile application to ping the server for any updates and notify the user.

Networking: This building block abstracts networking protocols like HTTP and HTTPs. It also provides a generator, which accepts WSDL files and generates client stubs that can be incorporated in the mobile application.

Telephony Module: This module allows for making/receiving calls, SMS functionality and Call Log Access.

Sensor Management: Devices ship with a set of sensors like Accelerometer, Temperature and Pressure sensors. This building block abstracts sensor management.

Synchronization Framework: Mobile applications are expected to function in a disconnected state, in case of no network coverage. The data is then expected to be saved on the device and then synchronized back to the server, when the network is available. This building block allows for a generic way in saving data locally and then synching it up to the Server.

Security: This building block supports utilities for encrypting/decrypting data.

Logging Framework: This building block supports all logging in an application via a unified interface. The logging can be set for different levels.

Internationalization: Internationalization is built from the start in all components. All messages displayed can be taken from the translation message files.

MVC Framework: The MVC Framework provides structure to the applications. An application controller is provided that controls all co-ordination between the widgets, external services
and data.


After having detailed the XEMP Platform, I suggest, we close the presentation by describing how this platform is used.

A. As a development platform with pre-designed services. Businesses can rapidly build their own applications using this platform.

  • As a series of solutions for businesses, Commercial Credit Card Services Mobilization for Financial Services companies.

  • Field Service Mobilization for Manufacturing/ Logistics businesses


Our client Commercial Credit Card Services Vendor

Our client, a global leader in commercial, retail and investment banking, currently has a web portal application available for commercial card reports and payment services. This web portal was built with Java/J2EE technology, WebLogic Server & Oracle DB. Existing functionality like business rules, payment gateway and enterprise integration was already implemented.

Our client wanted to allow users to access the commercial card services via a mobile application. The requirement from the mobile application was that it should function on majority of the handsets (devices).

Our client utilized the Xoriant Mobility Server to help mobilize the Commercial Card services and make it available on a wide range of devices and platforms. The High Level Architecture diagram is shown below.

A common REST Layer was built that exposed the commercial card functionality over XML/HTTP. This layer was the software contract between the devices and the client Business Services and Payment Gateway. The REST functionality implemented all the methods required i.e. login, get account summary, report data and payment transactions.

Once the REST layer was implemented, the requirement was to make it available from a wide range of mobile devices, which meant building Native Mobile clients in iPhone and Android in addition to making the services available from a Webkit based Smartphone browser.

For the Native Mobile clients, Xoriant Smartphone Apps Accelerator was used to rapidly build out the application on quality building blocks. The solution also utilized a Mobile Device Database (based on WURFL) to identify the Smartphone category of browsers and redirect the browser to the correct mobile implementation. This ensured that we not only used the same REST layer for both Native and Web Mobile clients but also provided a web based mobile solutions that will know how to progressively adapt for various mobile devices, based on their capabilities.



Infor ERP LN is a feature rich Enterprise Resource Planning system that contains various modules, including a the Sales and Service solutions. One of our clients has implemented Infor ERP LN at their site and gained significant improvement in optimized business processes. However in the filed sales and services operations, the existing business process took customer calls for service and handed them down to the field engineers manually on sheets of papers. The Field Service engineers would then visit each customer, perform the service, keep a track of inventory used and hours spent, and then come back at the end of the day to enter the updates into the Infor LN system.

The organization wanted to mobilize the entire Field Service module. There was no reason to leave the transactions and data lying inside of Infor LN. However, it was felt that it would be more productive for the field sales and service representatives to be able to access updated ERP data in the field to place orders, check inventory, process service orders from customer sites, all using their smart phones or mobile devices.

Xoriant XMS Server was utilized to help mobilize the Field Service operation. The High Level Architectural solution is shown below:

The project involved creating the Service Order Module, which was the domain modeling (as described above in the XMS section) of the entire data and operations that needed to be exposed to the mobile devices. XMS provided standard Infor LN Integration Adapter to make integration between XMS and Infor LN ERP a smooth process. The Scheduling Engine took care of synchronizing Master and Transactional Data between XMS and Infor LN at predefined intervals. Key to the mobilization was the definition of a Service Layer, which provided standards based REST layer that acted as the Service Contract between the Devices and XMS Server.

The customer implemented mobile applications for iPhone and Windows Mobile platform. Xoriant Smartphone Accelerator helped to speed up development of the mobile applications.

The new business process with mobility in place is described below:

Start of Day

The XMS Scheduling Engine executed Scheduled Jobs to extract Master & Transactional Data from Infor LN. This is typically done once a day, but can be scheduled at any different frequency by changing a simple parameter in the Scheduler.

Service Technicians use the mobile application; they authorize themselves and download the Master and Transactional Data from XMS.

Field Operations

The Service Technicians visit the customers and process the Service Order(s). The technicians input the information regarding the inventory consumed, time (hours, minutes) spent and any other expenses into the mobile app on their handheld. The mobile application saves all this data on the device.

End of Day

The Service Technicians return back to the organization and now that they have connectivity to the XMS Server, the use the mobile application to upload the data from their devices via the Synchronize functionality. XMS receives this data and marks it for synchronization with Infor LN. The Scheduling Engine then executes the synchronization using the Infor LN Adapter.

The data validation process before the data is input back into the Infor LN can be totally manual or rules based, where only the data not strictly satisfying the rules could be manually inspected.


Download The Whitepaper
2 + 6 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.