Skynax. Mobility Management System. System Manual

Transcription

1 Skynax Mobility Management System System Manual

2 Intermec by Honeywell th Ave. W. Everett, WA U.S.A. The information contained herein is provided solely for the purpose of allowing customers to operate and service Intermec-manufactured equipment and is not to be released, reproduced, or used for any other purpose without written permission of Intermec by Honeywell. Information and specifications contained in this document are subject to change without prior notice and do not represent a commitment on the part of Intermec by Honeywell by Intermec by Honeywell. All rights reserved. The word Intermec, the Intermec logo, and Skynax, are either trademarks or registered trademarks of Intermec by Honeywell. For patent information, please refer to Wi-Fi is a registered certification mark of the Wi-Fi Alliance. Microsoft, Windows, SQL Server, and the Windows logo are registered trademarks of Microsoft Corporation in the United States and/or other countries. Apple, ipad, iphone, itunes, icloud, the Apple logo, the itunes logo, and the icloud logo are registered trademarks of Apple Inc., registered in the U.S. and other countries. IOS is a trademark or registered trademark of Cisco in the U.S. and other countries and is used under license. Android and Google are trademarks of Google Inc. ii Skynax Mobility Management System Manual

3 Document Change Record This page records changes to this document. The document was originally released as Revision 001. Version Number Date Description of Change 002 3/2014 Revised to support Skynax Release 8.60, which includes the ability to manage Microsoft Windows Mobile, Apple ios, and Android mobile devices. Skynax Mobility Management System Manual iii

4 iv Skynax Mobility Management System Manual

5 Contents Contents 1 2 Before You Begin ix Safety Information ix Global Services and Support ix Warranty Information ix Web Support ix Send Feedback x Telephone Support x Who Should Read This Manual x Related Documents x About Skynax What s New in This Release? Skynax Features and Benefits Load Balancing Active Fail-Over System Maintenance with No Interruption to Operations Centralized Remote Administration Skynax Manager Remote Assist Console for Windows Mobile Devices Multi-Version Data Management Security and Efficiency Checkpoint Restart on Download Push Messaging Process Driven Connection Management Massive Scalability Skynax System Components Components of the Skynax Architecture Skynax Gateway Skynax Server Skynax Server Console Skynax MDM Service for ios Skynax Remote Assist Server Skynax Remote Assist Console Skynax System Monitor About Plug-Ins Skynax Plug-Ins Skynax System Plug-Ins Skynax Test Plug-Ins Skynax Mobility Management System Manual v

6 Contents Skynax Manager Skynax Packager Skynax Client for Windows Mobile and Android Devices Skynax Loader for Windows Mobile and Android Devices Skynax Data Services for Windows Mobile and Android Skynax Device Driver Skynax Database Microsoft SQL Server Mobile Business Applications for Windows Mobile Devices ios Applications for Apple ios Mobile Devices How to Create Custom Skynax Components Relationships Between the Skynax Components Skynax Communication Processes Process Numbers Process Load Balancing Active Fail-Over Connection Paths Push Messaging for Windows Mobile and Android Devices Checkpoint Restart on Downloads Network Address Translation How to Implement a Skynax System Implementation Overview Skynax System Topologies Supported Topologies About the Skynax Database About the Skynax Gateway and Skynax Server About Skynax Plug-Ins Sample Skynax System Topologies Single Computer Installation Dual Computer Installation with Basic Redundancy Multi-Computer Installation with Load Balancing and Fail-Over Multi-Computer Installation with Mandatory Skynax Servers vi Skynax Mobility Management System Manual

7 4 How to Manage a Skynax System Device Management Supported Devices Inside a Skynax Device Driver Primary and Subordinate Devices Device Properties Device Set Templates and Device Sets How to Work with Device Properties About System Codes for Windows Mobile How to Use System Codes in Skynax System Codes in Deployment Groups System Codes in Mandatory Server Groups System Codes in Plug-In Processes System Code Management System Code Pairing Spare System Codes System Code Management How to Deploy Software to Apple ios Devices How to Deploy Software to Windows Mobile and Android Devices Skynax Client Packages Skynax Device Driver Packages Business Application Packages Automated Business Application Package Deployments How to Update Mobile Business Applications for Windows Mobile or Android Devices 75 Register and Provision New Windows Mobile or Android Devices Re-Provision a Windows Mobile or Android Device How to Define Communication Rules for Windows Mobile and Android Devices Automatic Selection of Connection Paths Manual Selection of Connection Paths Connection Path Priorities How to Assign Processes to Connection Paths Communication Rules Taking Effect How to Work with Connection Paths Connection Path Processing System Plug-In Processes and Connection Paths Skynax Mobility Management System Manual vii

8 How to Route Connections in Public and Private Networks How to Work with TCP/UDP Ports in Skynax Structure of Communications Connections Mobile Business Applications for Windows Mobile and Android Devices viii Skynax Mobility Management System Manual

9 Before You Begin Before You Begin Safety Information This section provides you with safety information, technical support information, and sources for additional product information. Your safety is extremely important. Read and follow all cautions in this document before handling and operating Intermec equipment. You can be seriously injured, and equipment and data can be damaged if you do not follow the safety warnings and cautions. This section explains how to identify and understand warnings, cautions, and notes that are in this document. A caution alerts you to an operating procedure, practice, condition, or statement that must be strictly observed to prevent equipment damage or destruction, or corruption or loss of data. Note: Notes either provide extra information about a topic or contain special instructions for handling a particular condition or set of circumstances. Global Services and Support Warranty Information To understand the warranty for your Intermec product, visit the Intermec website at and click Support > Returns and Repairs > Warranty. Web Support Visit the Intermec website at to download our current manuals. Visit the Intermec technical knowledge base (Knowledge Central) at and click Support > Knowledge Central to review technical information or to request technical support for your Intermec product. Skynax Mobility Management System Manual ix

10 Before You Begin Send Feedback Your feedback is crucial to the continual improvement of our documentation. To provide feedback about this manual, please contact the Intermec Technical Communications department directly at Telephone Support In the U.S.A. and Canada, call Outside the U.S.A. and Canada, contact your local Intermec representative. To search for your local representative, from the Intermec website, click About Us > Contact Us. Who Should Read This Manual Related Documents This manual is intended for System Administrators, System Integrators, and other users who want to familiarize themselves with the concepts and theories on which Skynax is based. You may find these related Skynax documents useful: Skynax Mobility Management System User Manual Skynax Remote Assist User Guide Skynax Packager User Guide Skynax Mobility Management System Installation Guide Skynax Mobility Management System 8.60 Upgrade Instructions Skynax Data Services User Guide Skynax Push Messaging Integration Guide Skynax Server Plug-In Programmer Reference Manual Skynax System Codes Integration Guide Skynax Test Applications User Guide To download Skynax documents (as.pdf files) for free, log in to the Intermec INsider website at x Skynax Mobility Management System Manual

11 1 About Skynax Skynax Mobility Management System is a software solution that provides a reliable, scalable mobile communications system. This system is integrated with security, data management, device management, and extensible business application support features that are necessary for organizations to effectively deploy and manage mobile computing systems. The Skynax software architecture is flexible, configurable, and scalable, which allows organizations to configure and operate Skynax based on the size and complexity of their IT environment and business requirements. 1

12 Chapter 1 About Skynax What s New in This Release? This revision of the system manual describes the new features of Skynax Release 8.60, which includes the ability to manage Microsoft Windows Mobile, Apple ios, and Android mobile devices: Added information about the Skynax MDM Service for ios. See Skynax MDM Service for ios on page 11. Added a software components diagram that includes the Skynax MDM Service for ios. See Relationships Between the Skynax Components on page 21. Added information about ios applications. See ios Applications for Apple ios Mobile Devices on page 19. Added sections to describe two new System Code features. See System Code Pairing on page 69 and Spare System Codes on page 69. Added specific references throughout the manual to support Apple ios and Android mobile devices Note: Mobile devices running Apple ios can only access a limited range of Skynax functions. Throughout this manual: functions that are only supported by Microsoft Windows Mobile, Apple ios, or Android mobile devices are identified. the phrase Windows Mobile refers to all supported Windows Mobile and Windows Embedded Handheld operating systems. Skynax Features and Benefits The comprehensive management features of Skynax allow you to effectively control your entire mobile computing system from a central location. Note: Some features are only available in the Enterprise Edition of Skynax. For more information about the available features in each edition of Skynax, see the Intermec INsider website at 2 Skynax Mobility Management System Manual

13 Load Balancing Active Fail-Over Chapter 1 About Skynax Skynax provides these features and benefits: Load balancing Active fail-over System maintenance with no interruption to operations Centralized remote administration Multi-version data management Security and efficiency Checkpoint restart on download Push messaging Process driven connection management Massive scalability This feature allows you to derive maximum performance benefits by utilizing your server-side computing resources optimally. In live operations, Skynax Gateways continually monitor the performance of all Skynax Servers within a Skynax system. This information is used in combination with other information such as data processing queues to automatically redirect each mobile business application request for the exchange of business data, to the Skynax Server which is presently able to provide the fastest response time from all the Skynax Servers capable of managing the specific request. This feature helps to assure maximum mobile computing system uptime. In live operations, Skynax Gateways actively monitor the heartbeat of each Skynax Server in a Skynax system to automatically detect a failed Skynax Server and begin to automatically transfer each mobile business application s request for data exchange communications to one of the other functional Skynax Servers capable of managing the specific request. Skynax Mobility Management System Manual 3

14 Chapter 1 About Skynax System Maintenance with No Interruption to Operations You can independently shut down and upgrade each software component of Skynax. You can also upgrade and repair the underlying computing and networking infrastructure without interrupting Skynax operation. Centralized Remote Administration Skynax provides remote administration using these tools: Skynax Manager Remote Assist Console Skynax Manager Skynax Manager provides central control over the distributed mobile communication system, and supports system management from a remote location. For more information, see the Skynax Mobility Management System User Manual. Skynax Manager provides supports these functions: Remote configuration of mobile device operating parameters Remote interrogation of mobile device settings Central administration of all device assets Remote software deployment to mobile devices Mobile device monitoring and communications control Remote Assist Console for Windows Mobile Devices Remote Assist Console is a Microsoft Windows application (licensed separately) that allows Remote Assist operators to collaboratively support mobile device users. Users request support from a defined list of problem categories so that requests are routed to the appropriate Remote Assist operator group. Additionally, Remote Assist operators can: invite other operators to a Remote Assist session to collaborate to solve problems. initiate a connection to a mobile device and remotely see and control the mobile device screen without any interaction with the user. 4 Skynax Mobility Management System Manual

15 Chapter 1 About Skynax remotely see and control multiple mobile device desktops. get and send files using the built-in File Explorer application. record video or take screen shots of a Remote Assist session. Multi-Version Data Management Security and Efficiency Skynax supports the simultaneous processing of data communications for thousands of mobile device users, running different mobile applications in different versions and using different device settings, while ensuring the integrity of the business data being exchanged with multiple, different host system interfaces. Skynax provides automatic compression and encryption of all data transmitted between a mobile device and server computer to minimize bandwidth utilization and provide data exchange security, including: centrally managed authentication of mobile devices. centrally managed authentication of mobile device users. automated encryption key management. Checkpoint Restart on Download Push Messaging Skynax can resume a file download at the point of download failure. The ability to quickly continue a large file download, at the point where communications were interrupted, without having to restart your file download from the beginning saves both time and money. Skynax push messaging features allow host systems to remotely launch mobile device applications on demand, as well as send messages to target mobile devices available within the network. The mobile device runs the Skynax Client Push Message Service, which places each message received in a queue. Mobile business applications can extract messages from the queue and initiate the required actions. Skynax Mobility Management System Manual 5

16 Chapter 1 About Skynax Process Driven Connection Management Massive Scalability This feature allows the Skynax administrator to establish the communications rules that will be applied by Skynax Clients when establishing network connections to exchange of business data. Connection management in Skynax is process aware, meaning that connections are established and used based on generic criteria, such as the time of day, the types of network connectivity available, and the business data that the Skynax Client exchanges. A Skynax administrator can modify the communication rules used by the mobile computing system without the added cost, time, and risk involved with making custom changes to a mobile business application. Skynax Servers provide substantial scalability by allowing the peak load of communications and server-side data processing to be executed in parallel using multiple processors in a single computer as well as multiple computers in a Skynax system. Increasing the scalability of a Skynax system can be as easy as adding an additional Skynax Server to your existing Skynax system. 6 Skynax Mobility Management System Manual

17 2 Skynax System Components The Skynax system components work together to provide an integrated and secure system for mobile data communications, data management, and device management. 7

18 Chapter 2 Skynax System Components Components of the Skynax Architecture The Skynax architecture is comprised of software components. A component can be an executable application, a program library containing functionality that can be called by another application to perform specific tasks, or a structured data repository. Overview of Skynax Software Components Component Skynax Gateway, or Gateway Skynax Server, or Server (not to be confused with a computer server) Skynax Server Console Skynax MDM Service for ios Skynax Remote Assist Server Skynax Remote Assist Console Skynax System Monitor Skynax Plug-In Skynax System Plug-In Description A server-side application that functions as an entry point into the Skynax system. A server-side application that accepts and handles Skynax Client requests that are redirected from a Skynax Gateway. A server-side application that provides a visual monitor of the communications processing on a Skynax Server. (Apple ios) The Skynax MDM Service for ios allows Skynax to manage Apple ios mobile devices. A server-side application that acts as a bridge between the Remote Assist Console and the Skynax Client on the mobile devices. A Microsoft Windows application (licensed separately) that allows Remote Assist operators to collaboratively support users of the mobile communication system. A server-side application that provides a basic visual indicator of the operating status of all Skynax Servers and Skynax Gateways within a single Skynax system. A server-side application that processes the data exchanged for each Skynax Client request. A special Skynax Plug-In application that is used to perform system-level functions. For More Information, See Skynax Gateway on page 10. Skynax Server on page 10. Skynax Server Console on page 11. Skynax MDM Service for ios on page 11. Skynax Remote Assist Server on page 11. Skynax Remote Assist Console on page 12. Skynax System Monitor on page 12. Skynax Plug-Ins on page 13. Skynax System Plug-Ins on page Skynax Mobility Management System Manual

19 Overview of Skynax Software Components (continued) Chapter 2 Skynax System Components Component Skynax Test Plug-In Skynax Manager Skynax Packager Skynax Client Skynax Loader for Windows Mobile and Android Skynax Data Services for Windows Mobile and Android Skynax Device Driver Skynax Database Microsoft SQL Server Mobile Business Application, or mobile application ios Application Description An application that works with the Skynax Test Client applications to verify connectivity and test Skynax system performance in an organization s communications infrastructure. A server-side application that operates as the Skynax control center. A stand-alone application that lets you bundle files into packages. A client-side application for Windows Mobile and Android devices that allows Skynax to process data transfer requests from Skynaxenabled mobile business applications. A client-side application used to register a mobile device to a specific Skynax system. A set of interfaces that allows mobile business applications to use Skynax communications and data management functions. An application designed to work with the Skynax Client and control a specific type of mobile device. The central structured repository for all Skynax system configuration settings that control how the Skynax systems operates. A separate application that handles requests from Skynax applications to access the Skynax Database and retrieve or store information. A software application that runs on a Windows Mobile device. A software application that runs on an Apple ios mobile device. For More Information, See Skynax Test Plug- Ins on page 14. Skynax Manager on page 15. Skynax Packager on page 15. Skynax Client for Windows Mobile and Android Devices on page 16. Skynax Loader for Windows Mobile and Android Devices on page 16. Skynax Data Services for Windows Mobile and Android on page 17. Skynax Device Driver on page 17. Skynax Database on page 18. Microsoft SQL Server on page 18. Mobile Business Applications for Windows Mobile Devices on page 19. ios Applications for Apple ios Mobile Devices on page 19. Skynax Mobility Management System Manual 9

20 Chapter 2 Skynax System Components Skynax Gateway Skynax Server The Skynax Gateway is a server-side application that functions as an entry point into the Skynax system. This application runs as a service in the operating system of a server-side computer, so it does not have a user interface. When a Skynax Client sends a request to establish a connection and exchange data in a Skynax system, it must first connect to a Skynax Gateway for authentication. After the Skynax Gateway has determined the validity and access rights of the connecting mobile device, it redirects the requests coming from the Skynax Client to a Skynax Server, based on the identifier of the Plug-In process being requested and the current processing load of each computer presently running a Skynax Server. For a visual diagram of this process, see Relationships Between the Skynax Components on page 21. Skynax Gateways are also used to implement Skynax push messaging features. Skynax Gateways provide the direct push capabilities needed to deliver messages to Skynax Clients running on target mobile devices that are accessible within the network. Push messaging provides for greater responsiveness and faster business process execution in a mobile computing system. For more information about push messaging, see Push Messaging on page 5. The Skynax Server is a server-side application that accepts and handles Skynax Client requests redirected from a Skynax Gateway. The Skynax Server application runs as a service in the operating system of a server-side computer, so it does not have a user interface. When a mobile device sends a request to exchange data in a Skynax system, it must provide an identifier, or process number. The process number identifies the Skynax Plug-In process used to handle the request on a Skynax Server. The Skynax Gateway directs the request and its process number to a Skynax Server. The Skynax Server then uses the process number to determine the appropriate Plug-In to call, which allows a bidirectional flow of business data between the Skynax Server and the Skynax Client on the mobile device. For a visual diagram of this process, see Relationships Between the Skynax Components on page Skynax Mobility Management System Manual

21 Skynax Server Console Chapter 2 Skynax System Components The Skynax Server Console is a server-side application that is typically installed on the same computer as a Skynax Server. Because the Skynax Server runs as a service on the operating system and does not have a user interface, the Skynax Server Console application provides a view into the operation of a Skynax Server. The Skynax Server Console provides a near real-time, continuous, read-only visual monitor of the communications processing taking place on a Skynax Server. This application allows you to observe a Skynax Server s handling of communications during daily operations. It also provides a detailed view into the data being transmitted within each communication session and is therefore beneficial when seeking to identify the source of any connection or data management problem. For Skynax implementations with more than one Skynax Server, you may want to install the Skynax Server Console on a remote computer (such as the desktop computer of the mobile computing system administrator). Then, you can register each Skynax Server to that Skynax Server Console so that it can provide a single point for Skynax Server monitoring. Skynax MDM Service for ios The Skynax MDM Service for ios is a server-side application that is installed on the same computer as the Skynax Server. This application allows the System Administrator to manage Apple iphone and ipad mobile devices from within their Skynax system. For a visual diagram of this process, see the illustration Skynax Software Components with the Skynax MDM Service for ios on page 22. Skynax Remote Assist Server Skynax Remote Assist Server is a server-side application that runs as a service in the operating system of a server-side computer. The Skynax Remote Assist Server acts as a bridge between the Remote Assist Console application and the Skynax Client that runs on mobile devices. All Remote Assists sessions are driven and controlled through this service. To use Skynax Remote Assist features, this service must be active. Skynax Mobility Management System Manual 11

22 Chapter 2 Skynax System Components Skynax Remote Assist Console Skynax System Monitor About Plug-Ins The Skynax Remote Assist Console is a Microsoft Windows application (licensed separately) that allows Remote Assist operators to collaboratively support Windows Mobile users. Remote Assist operators can: remotely connect to and control multiple mobile devices. invite other operators to a Remote Assist session to collaborate to solve problems. initiate a connection to a mobile device and remotely see and control the mobile device screen without any interaction with the user. send and receive files using the built-in File Explorer application. record video or take screen shots of a Remote Assist session. The Skynax System Monitor is a server-side application that provides a basic visual indicator of the operating status of all Skynax Servers and Skynax Gateways within a single Skynax system. This application is typically installed on the same computer as Skynax Manager, however it may be installed anywhere that requires a central monitoring dashboard for the Skynax system. Plug-Ins process the business data exchanged for each Skynax Client request. The Plug-In receives the data associated with a request, processes the data according to its programmed business data processing logic and possibly responds to the request. The actual processing performed by a Plug-In is limited only by the needs of the developer who is creating the Plug-In. For a visual diagram, see Relationships Between the Skynax Components on page Skynax Mobility Management System Manual

23 Chapter 2 Skynax System Components Skynax Plug-Ins The Skynax Plug-In application is designed to run on a Skynax Server and is typically provided with a specific version of a Skynax-enabled mobile business application. Skynax Manager loads Plug-In files onto Skynax, which then stores these files and related Plug-In information in the Skynax Database. Based on the settings you define in Skynax Manager, remote Skynax Servers automatically extract Plug-In program files from the Skynax Database and install those files on its local computer. Each installed Plug-In program is then automatically called by a Skynax Server to process a specific request (identified by a unique process number) sent to it from a mobile business application. A Plug-In does not have to be dedicated to processing a single type of request that is, the Plug-In is not limited to processing requests that are associated with only one process number. A single Plug-In can support multiple processes (multiple types of requests from a mobile business application) with each process in the Plug-In having its own unique process number. The Plug-In developer determines which processes are aggregated into a single Plug-In program. More information on this topic is included in the Skynax SDK (Software Development Kit). A Plug-In does not run continuously on a Skynax Server but rather a separate copy of the Plug-In is loaded into memory and runs each time the Skynax Server calls the Plug-In to process a new request. Essentially, the Skynax Server creates as many independent, virtual clones of a Plug-In as is needed to manage all new incoming requests. A Plug-In can exchange data using any number of methods such as the transmission of a file, the direct manipulation of records in a database, interacting with a web service or parsing an XML document and executing a remote function call to a host system. Because a Plug- In contains the intelligence to understand the data that is being passed to it, the Plug-In can process the data in an event driven style, performing different tasks and starting and stopping different auxiliary systems based on the data and when it is received. Skynax Mobility Management System Manual 13

24 Chapter 2 Skynax System Components Sample Scenario If a mobile application detects some input of interest, it may be designed to initiate a connection to Skynax with a specific process number, whereby the Plug-In called to manage that process on the Skynax Server interprets the data received from the mobile application and performs some action on it, such as generating a report and sending it by or effecting an alert on a digital dashboard used to oversee business operations. The Plug-In actually contains the specific business intelligence (business process logic) needed to handle the exchanged business data. The processing performed by a Plug-In is independent of the Skynax Server and all other Skynax components. The functionality of a Plug-In is determined by the organization s business data processing needs and this functionality can be created and modified as needed. To develop Plug-Ins for your own mobile business applications, see the Skynax SDK. Skynax System Plug-Ins A System Plug-In is a special type of Skynax Plug-In application that is pre-installed with a Skynax Server and is used to perform system level functions. These system level functions perform tasks such as deploying software packages to a mobile device and remotely configuring a mobile device. The behavior of these System Plug-In programs is controlled by the configuration settings defined in Skynax Manager. Skynax Test Plug-Ins The Test Plug-In program, available with each Skynax system, is designed to work together with the Skynax Test Client applications to verify communications connectivity, and test over-all performance of the Skynax system in your organizations communications infrastructure. 14 Skynax Mobility Management System Manual

25 Skynax Manager Skynax Packager Chapter 2 Skynax System Components Skynax Manager is a server-side application that operates as the control center of Skynax. Almost everything that can be configured, tracked, and managed in Skynax is done through Skynax Manager. It is the single most important application available to the Skynax administrator. It offers a user-friendly, easy to navigate interface encompassing all Skynax modules and related configuration settings. Skynax Manager is typically installed on a separate desktop or notebook computer but may also be installed directly on the computer where other Skynax components, such as the Skynax Gateway or Skynax Server, are installed and running. Skynax Manager may also be installed on multiple computers to provide more users with access to Skynax system information. Each person that is added as a user of Skynax Manager is automatically assigned reader rights within Skynax, which means that they will have a read-only view to all configuration settings, while users assigned administrator rights will also have the option to modify the configuration settings of each Skynax module. Changes to the configuration settings defined in Skynax Manager are valid in a Skynax system from the moment these changes are made, and therefore these changes will immediately be reflected in the behavior of Skynax within a mobile computing system. Multiple users can log in to Skynax Manager as an administrator at the same time. If you attempt to edit something in Skynax Manager while another user is editing the same information, or information that depends on the settings you are trying to modify, Skynax Manager alerts you to this conflict. Skynax Packager is a stand-alone application that allows you to bundle files into packages that can be loaded into Skynax Manager for automatic, remote installation to your mobile devices. These packages typically contain the files required to install a Skynax Client, Skynax Device Driver or a mobile business application. The Skynax Packager application allows you to define where the files in a package will be installed, which files should be deleted from the mobile device, as well as modify registry settings in the operating system. Skynax Mobility Management System Manual 15

26 Chapter 2 Skynax System Components Skynax Client for Windows Mobile and Android Devices The Skynax Client is a a collection of several self-running mobile applications and Dynamic Linked Library (DLL) files that are installed jointly on Windows Mobile and Android devices (such as mobile computers, tablet computers, and notebook computers), as well as in Skynax system. All communications between the mobile device and the server are compressed and encrypted. The Skynax Client supports these functions: Register the device with the Skynax system Process the initial device provisioning Receive and install business applications and application updates Receive and install updates for Skynax device drivers and clients Manage device settings through templates configured on the server Upload client operational logs and events logged by business applications to the server Request or accept remote assistance (Windows mobile only) Use the messaging service for data management For a visual diagram, see Relationships Between the Skynax Components on page 21. Skynax Loader for Windows Mobile and Android Devices The Skynax Loader application is installed on a mobile device as part of the Skynax Client package. This application is first used to register the mobile device with a specific Skynax system. After the device registration is approved by a Skynax administrator, Skynax Loader can use a System Code (with an optional password) to connect through a Skynax Gateway and receive its initial provisioning. The initial provisioning configures device settings, upgrades Skynax Client components, and installs the business application. 16 Skynax Mobility Management System Manual

27 Chapter 2 Skynax System Components After the initial provisioning is complete, Skynax Loader is no longer necessary. Other components of the Skynax Client keep the device settings, components, and application upgrades synchronized with the server. However, Skynax Loader can be used to re-purpose the mobile device by re-provision the device to use a different System Code. Note: The Skynax Loader application used to register Apple iphone and ipad mobile devices is different. Provisioning for ios mobile devices is performed through a web service. For more information, see the Skynax Mobility Management System Installation Guide. Skynax Data Services for Windows Mobile and Android Skynax Device Driver Skynax Data Services is a set of interfaces that allows mobile business applications to use Skynax communications and data management functions. Skynax Data Services is contained in a client-side executable (Skynax Data Service) and is an integral part of the Skynax Client. The Skynax Data Service Plug-In is the server-side counterpart of the Skynax Data Service on the client. Mobile business applications can register themselves to use Skynax Data Services by storing a configuration file in the Skynax application folder on the client. After an application is registered to use Skynax Data Services, the application can use Skynax Data Service command files to upload and download data, which allows it to leverage Skynax features without having to use low level programming interfaces. The details of the configuration file structure used for registration and the command files are described in the Skynax SDK and developer documentation. A Skynax Device Driver is an application that works with the Skynax Client to control a specific type of mobile device. You can download the Skynax Device Drivers you need from the Intermec INsider website at and install them in a Skynax system to provide that system with the ability to manage new types of mobile devices. Skynax Mobility Management System Manual 17

28 Chapter 2 Skynax System Components Skynax Database Microsoft SQL Server Use Skynax Manager to install new and updated Skynax Device Drivers in your Skynax system. When a new Skynax Device Driver is installed, Skynax Manager reads the associated Skynax Device Driver information file and uses this information to create new entries in the Skynax Database. These entries show the new type of mobile device supported in the Skynax system and what new device configuration properties can be used to remotely modify and retrieve this device s settings. Note: Skynax Device Drivers are not the same as device drivers provided by various hardware manufacturers or other drivers available in the Microsoft operating system. Skynax Device Drivers serve as enablers that allow the same Skynax Client to control many different types of devices. The Skynax Database, located on a server-side computer running Microsoft SQL Server, is the central structured repository of all Skynax system configuration settings that control how a given Skynax system will operate. The Skynax Database also stores all log transaction information that is created by Skynax applications, all software packages available for distribution to mobile devices, and all Plug-In programs available within your Skynax system. The Skynax Database is automatically created on the Microsoft SQL Server, during the initial steps of a Skynax system installation, using the Skynax Database Setup Program. All the components of Skynax operate according to the configuration settings defined in Skynax Manager and stored in the Skynax Database. The Microsoft SQL Server application, which is itself not a component of Skynax, handles the requests from Skynax applications to access the Skynax Database and retrieve or store information. Therefore, to function properly, Skynax must have access to a properly configured and operational Microsoft SQL Server application and its Skynax Database. For small mobile business systems, it may be sufficient to use Microsoft SQL Server Express Edition. 18 Skynax Mobility Management System Manual

29 Chapter 2 Skynax System Components If you downloaded a trial version of Skynax, you can also download the installation files for SQL Server Express Edition from The Express Edition is not equivalent to Microsoft SQL Server. Express Edition has performance and database size limitations which must to be considered before making a decision to use Skynax in a live environment with these versions of SQL. For more information on the limitations Express Edition see the Microsoft technical specifications. Note: If you use Microsoft SQL Server as your Skynax database server, you need to purchase the appropriate Microsoft SQL Server and SQL Client Access Licenses. If you have more than 50 mobile devices in your mobile computing system, your most economical option may be the Microsoft per-processor licensing model for the standard edition of SQL Server. Mobile Business Applications for Windows Mobile Devices A mobile business application, or mobile application, is a software application that runs on a Windows Mobile device. The mobile application is not a component of the Skynax system, although it can be designed to interact closely with Skynax via the Skynax Client and is an integral part of the complete mobile business system solution. A mobile application can be anything its developers want it to be: it can serve the needs of a particular industry or organization, it can be simple and require only regular batch transfers of data, or it can be complex and require many different types of on-line data exchanges. Skynax-enabled mobile business applications that address a wide variety of business needs are available from Skynax Implementation Partners. Regardless of its intended purpose and complexity, a Skynax-enabled mobile application is ready to take advantage of the communications, data, and device management capabilities of Skynax. ios Applications for Apple ios Mobile Devices An ios application is a software application that runs on an Apple iphone or ipad. ios applications are distributed through the itunes App Store. Skynax Mobility Management System Manual 19

30 Chapter 2 Skynax System Components How to Create Custom Skynax Components To create your own specific Skynax components, you need the Skynax SDK. Skynax software components developed by independent software vendors are licensed independently by each software vendor according to their terms and conditions. The Skynax SDK is an invaluable resource for developers and integrators of mobile business application solutions. It contains everything you need to quickly get your mobile business application up and running with Skynax. The Skynax SDK includes: documentation for Skynax Data Services, which allows you to develop Skynax-enabled mobile business applications that can control and communicate with a Skynax Client running on a mobile device. documentation for the Skynax Server API, which allows you to develop Plug-In programs that run on a Skynax Server and are able to receive and respond to requests from a Skynax-enabled mobile application. extended explanations for creating a Plug-In that runs on a Skynax Server with open, reusable source-code to sample Plug-In programs. an application template component that you can install in Microsoft Visual Studio to automatically create the necessary source code framework to write a custom Plug-In. This eliminates the need to write the source code wrapping needed to create the Plug-In framework and allows a developer to simply concentrate on creating the specific program logic that will process the business data that the new Plug-In is being designed to handle. 20 Skynax Mobility Management System Manual

31 Chapter 2 Skynax System Components Relationships Between the Skynax Components The following illustrations depict the Skynax software components introduced in the previous pages and their relationship to each other based on the way they share and exchange information (indicated with arrows between the various components). CORE INFRASTRUCTURE Host Computer Host System Data Interface for Process No Host System Data Interface for Process No Middleware Computer Skynax Manager Skynax Server Console System Setup Exchange business data for Process No with host system. Exchange business data for Process No with host system. Skynax Database Server Monitoring Device Settings & Package Deployments System Plug-In Processes Plug-In Process No Ver Plug-In Process No Ver Skynax Gateway Skynax Server Network Infrastructure (Ethernet, Wi-Fi, Modem, GPRS, CDMA) Authentication and Connection Forwarding Device Settings and Software Deployment Data Exchange for Process No Data Exchange for Process No Mobile Computer Initial Device Provisioning Request for Process No Ver Skynax Client Request for Process No Ver Skynax Device Drivers Skynax Loader Mobile Business Application MOBILE DEVICE INFRASTRUCTURE Skynax Software Components without the Skynax MDM Service for ios Skynax Mobility Management System Manual 21

32 Chapter 2 Skynax System Components Skynax Software Components with the Skynax MDM Service for ios 22 Skynax Mobility Management System Manual

33 Skynax Communication Processes Process Numbers Chapter 2 Skynax System Components A communication process is the uniquely identifiable request for an exchange of data that is initiated by the mobile business application via the Skynax Client on the mobile device and transmitted to and possibly responded to by a Plug-In running on a Skynax Server. The contents of a communications process, or simply process for short, may be anything the developers of the mobile application and Plug-In program agree to exchange. The contents of a process may include anything that the developers of the mobile application and Plug-In program agree to exchange. This means that as long as the mobile application and Plug-In are both aware and synchronized with respect to how data sent by each side should be processed and responded to by the other side, the actual data transmitted is entirely up to these applications, and is in no way constrained by Skynax. A process can be as simple as uploading a file from a mobile device to a server side computer, but processes can also be much more complex. For example, a process can involve a series of integrated requests and responses for someone who uses a mobile application to interrogate an ERP application online over a GPRS connection to check the stock status of an item or post a new customer order and schedule product deliveries. For more information about how to design a Plug-In to manage a specific process, see the Skynax SDK. To understand how data is routed between Skynax applications, or between a mobile device to a server side computer, you need to understand process identifiers and connection paths. Each process requested by a mobile application is identified by its process number. Each requested process number must match a process number coded in the Plug-In called by the Skynax Server on which it is installed. The Plug-In is responsible for managing the incoming process request from the mobile application (receiving the data, processing the data as needed and responding to the received data as expected according to the data exchange interface agreed upon between the developers of the mobile application and the Plug-In). Skynax Mobility Management System Manual 23

34 Chapter 2 Skynax System Components Each Plug-In can support one or more processes based on the process numbers encoded in the Plug-In itself. Using Skynax Manager we can view which Plug-In is installed on which Skynax Server as well as the type of processes each Plug-In supports and their process numbers. Moreover, the Skynax Gateway application which is responsible for authentication and redirection of a Skynax Client request to a Skynax Server application, determines which Skynax Servers are able to manage the incoming process by looking at the process number sent by the Skynax Client and comparing it to the process number coded in each Plug-In that is registered in the Skynax Database together with the Skynax Servers on which it is available. The mobile application that exchanges data with a server sends a request to the Skynax Client to establish a connection to Skynax for the specified process number. When the Skynax Client receives a request from a mobile application for a particular process number, it attempts to establish a valid connection to Skynax by connecting to a Skynax Gateway and transmitting the requested process number to it. The Skynax Gateway uses this process number to determine the which Skynax Server should be used by the Skynax Client. To make this determination, the Skynax Gateway sees which Skynax Servers have a Plug-In that is capable of managing the requested process, and considers which Skynax Server has the lowest work load. Process numbers are assigned and used by mutual agreement between the developer of the mobile application and the developer of the Plug- In program - process numbers are embedded in these cooperative programs and are not modifiable using Skynax Manager. To install a Plug-In program using Skynax Manager, you select the Plug-In's associated PLI file (Plug-In Information file) which contains the information needed to install the Plug-In, such as process numbers, process versions, process properties, process descriptions, and so on. Skynax Manager stores this information in the Skynax Database together with a binary copy of the Plug-In program. A Plug-In program is installed automatically on a Skynax Server as a result of having one of the processes that it supports assigned to that Skynax Server. You control this assignment using Skynax Manager. Using Skynax Manager, you can then modify selected property settings for 24 Skynax Mobility Management System Manual

35 Process Load Balancing Active Fail-Over Chapter 2 Skynax System Components the Plug-In, as well as assign the connection paths that will be valid for each of the processes which the Plug-In can handle. Based on this information the Skynax Gateway and Skynax Server are able to properly route each process requested by a mobile application to the Plug-In responsible for managing that process. Each Skynax Gateway continuously monitors the status and processing load of all Skynax Servers running in a Skynax System. Based on this continuously updated stream of information a Skynax Gateway will route a Skynax Client and each newly requested process to the Skynax Server that is presently capable of handling the request and providing the best response time. (In this context, a Skynax Server is considered capable of handling the request if it has a Plug-In installed that contains a process identified by a process number that is the same as the process number of the incoming request). This function of Skynax provides the benefits of load balancing because it distributes the full load of incoming process requests among the available Skynax Servers (meaning all Skynax Servers that are capable of managing each request by having the appropriate Plug-In installed) based on how heavily each Skynax Server is presently being utilized. Note: Load balancing is available only in the Enterprise Edition of Skynax. In the event that any Skynax Server should fail to respond to the special Skynax Server monitoring service of a Skynax Gateway (such as a physical hardware failure of the Skynax Server s computer or the Skynax Server s computer is inadvertently shut down) the Skynax Gateway automatically triggers active fail-over functionality which will inactivate the problematic Skynax Server in the list of available Servers and redirect all subsequent Skynax Client process requests to other Skynax Servers capable of managing the specific processes. When the problem with the inactive Skynax Server has been resolved, the Skynax Server automatically notifies the Skynax Gateway that it is again available for processing whereby the Skynax Gateway reactivates it and the Skynax Server continues normal operation within the Skynax Mobility Management System Manual 25

36 Chapter 2 Skynax System Components Skynax system. This functionality allows any Skynax Server within a Skynax system to be shut down without causing any interruption to mobile data communication services - provided that the same processes supported by the Skynax Server being shut down are also supported by at least one other running Skynax Server. The fail-over functionality is not limited to Skynax Servers in a multicomputer Skynax Server implementation but is also available in multi-computer Skynax Gateway implementations. A multicomputer Skynax Gateway implementation is used to allow each Skynax Client to use more than one Skynax Gateway whenever it is attempting to establish a valid connection. This approach assures that the failure of any one Skynax Gateway will not prevent mobile applications from reaching their requested Plug-In processes. Note: Active fail-over is available only in the Enterprise Edition of Skynax. Connection Paths A connection path specifies the type of connectivity that can be used by a mobile device to connect to a Skynax Gateway or Skynax Server to exchange data with each process; each process number that can be requested by one of your mobile business applications. (In other words, in order for a mobile business application to be able to request any given process number you must first define a connection path through which that process number can be requested from a mobile device.) You configure connection paths using Skynax Manager. The type of connectivity you can define for each connection path will be based on the types of network connectivity available and supported by Skynax on each mobile device that you are using. Therefore, a mobile device having a built-in and supported GSM modem, Ethernet LAN adapter, and an Wi-Fi radio has the ability to establish three different types of connections. Each process number defined within a Plug-In, that is assigned to run on a Skynax Server, is also having assigned to it the type of connectivity that can be used by a Skynax Client when attempting to establish a connection from a mobile device to request the given Plug-In process. 26 Skynax Mobility Management System Manual

37 Chapter 2 Skynax System Components Using Skynax Manager, you can also set the times during which a particular connection path will be available for use by a Skynax Client. In practice, this means that you can define when the Skynax Client will be able to establish certain types of network connections for specific Plug-In processes, thereby allowing you to control which data (based on the process number) will be exchanged over which communication infrastructure and when such an exchange of data may occur. In Skynax Manager, you can define more than one connection path for each particular process number and also set a priority for each connection path. When you define multiple connection paths with different priorities for a given process, the Skynax Client on the mobile device always attempts to establish a connection for the requested process in your defined order of connection path priority. Sample Scenario 1 The download of a large product catalog file to a mobile device is not allowed during normal working hours, as your communication infrastructure is busy at that time. At off-peak times, the Skynax Client must follow these connection path priorities: 1 Use the LAN adapter if a LAN connection is available. 2 Use the Wi-Fi radio if a Wi-Fi access point is available. 3 Use the GPRS radio. In the previous scenario, in Skynax Manager, you would define three connection paths, one for each type of connectivity that the mobile device can support (LAN, Wi-Fi, and GPRS) and set each connection path to be valid only during off-peak hours. Additionally, you would set the connection paths in decreasing priority based on your above defined preferences, so as an example you would set the connection path using LAN as priority 1, the one using the Wi-Fi as priority 2 and the one using GPRS as priority 3. Finally, you would assign the process number that is used by the mobile application to request and receive the large product catalog file from the Plug-In to all three connection paths. This configures Skynax to allow the large catalog file to be downloaded to a mobile device only during off-peak hours Skynax Mobility Management System Manual 27

38 Chapter 2 Skynax System Components using all three available communication types, however forcing the Skynax Client to automatically first attempt to download the file using a LAN connection, followed by a Wi-Fi connection and lastly if the prior two connection types are not available then to try to connect and download the file using GPRS. Plug-In with Process Number 1150 Skynax Server Plug-In with Process Number 6920 Skynax Server Connection Path 1 (LAN) Connection Path 2 (Wi-Fi) Connection Path 3 (GPRS) Connection Path (Wi-Fi) Connection Path (LAN) Connection Path 3 (GPRS) Skynax Client Skynax Client Mobile Business Application requests process number 1150 Mobile Business Application requests process number 6920 Off-peak time restriction is the same for all three connection paths: 06:00pm 05:00am Process Number 1150 Process Description: download product catalog file CP1 w/ Priority 1 CP2 w/ Priority 2 CP3 w/ Priority 3 Example: Connection Path Scenarios Process Number 6920 Process Description: CP w/ Priority 1 CP w/ Priority 2 CP3 w/ Priority 3 The ability of the Skynax Client to efficiently handle simultaneous processing using multiple connection paths is especially important in the event that several processes are requested by the mobile application at the same time or in such rapid succession that the previously requested process has not yet been completed before a new process request is generated by the mobile application. In such a case, the Skynax Client on the mobile device first determines if a connection to a Skynax Server has already been established through any given connection path. If a connection has already been established, the Skynax Client determines if that connection path may also be used for the new process being requested by the mobile application, based on the connection type of the connection path (ignoring the connection path priorities) defined in Skynax Manager. If the new process being requested is also set to be able to use the 28 Skynax Mobility Management System Manual

39 Chapter 2 Skynax System Components currently established connection, ignoring all priority settings, then the Skynax Client creates a new session within the current connection, to handle the data exchange for this new process. However, if the new process being requested is not defined in Skynax Manager as able to use the type of connection already established then the Skynax Client attempts to establish a new connection to handle this process, based on your defined connection path rules. The Skynax Client automatically closes each connection after all sessions within a connection have terminated. Skynax Server Plug-In Process # 1150 Connection 1 Session 1 Skynax Client Mobile Business Application Requests Process # 1150 Plug-In Process # 6920 Session 2 Requests Process # 6920 Plug-In Process # Connection 2 Session 3 Requests Process # Connection Path Processing In pull communication scenarios, communication sessions are initiated by the Skynax Client on the mobile device. In push communication scenarios, communications sessions are initiated by the Skynax Gateway (typically on demand of a host system). Push communication scenarios are supported by Skynax through Skynax Push Messaging Services. These services allow host systems to initiate the exchange of business data by sending messages to the mobile business application on a target device. These messages are intercepted by the Skynax Client Push Message Service on the mobile device, stored in a local message queue, and the mobile business application obtains a windows message letting it know that it can now fetch new messages from the queue. These messages can: provide new business data to the mobile business application. encode instructions to the mobile business application. remotely launch applications on the mobile device. Skynax Mobility Management System Manual 29

40 Chapter 2 Skynax System Components All configuration settings, including connection path rules, defined in Skynax Manager that are to be used by the Skynax Client on a mobile device are automatically replicated to the mobile device and processed by the Skynax Client each time the Skynax Client attempts to connect to a Skynax system. Sample Scenario 2 You have a Plug-In process that, when request by a Skynax Client, sends a series of large files to the mobile device. The user s mobile device can only establish a LAN or GPRS connection. In this scenario, we would use Skynax Manager to configure two connection paths with the appropriate settings, one for each of the types of connectivity supported by our mobile devices (in the diagram below this is represented by Connection Path 1 and Connection Path 2). Furthermore, in the diagram we show that this Plug-In process is identified as process number The assignment of process number 1150 to connection paths 1 and 2 in Skynax Manager forces the Skynax Client to first attempt to establish connections for this process using a LAN network and if this is unavailable then use a GPRS network during the time between 5:00PM and 7:00AM. This Skynax functionality has many potential uses, including the control of mobile communication costs. Connection Path 4 Parameters: Connection Type: Wi-Fi Time restrictions: None Priority: 1 Plug-In Skynax Server Plug-In Connection Path 1 Parameters: Connection Type: LAN Time restrictions: None Priority: 1 Connection Path 5 Callable Process: Process # 6920 Callable Process: Process # 1150 Connection Path 2 Parameters: Connection Type: GPRS Time restrictions: 5:30PM to 6:30PM Priority: 2 Parameters: Connection Type: GPRS Time restrictions: 5:00PM to 7:00AM Priority: 2 Connection Path 6 Parameters: Connection Type: LAN Time restrictions: 4:00AM to 7:00AM Priority: 1 Plug-In Callable Process: Process # Callable Process: Process #25369 Callable Process: Process #25300 Connection Path 3 Parameters: Connection Type: GPRS Time restrictions: 5:00PM to 7:00AM Priority: 1 Example: Skynax Plug-In Process Skynax uses System Plug-Ins that contain special processes which are used to exchange system data (not business data) between Skynax Servers and Skynax Clients. These System Plug-In processes have process numbers starting with and higher (this range of process numbers is reserved exclusively for use by System Plug-In process). 30 Skynax Mobility Management System Manual

41 Chapter 2 Skynax System Components Software developers and integrators are strongly urged not to create or use custom Plug-Ins that contain processes with process numbers in the above reserved process number range. Doing so may complicate future Skynax system updates or upgrades as well as cause operational problems when Skynax Clients are unable to connect to the expected System Plug-In process. Push Messaging for Windows Mobile and Android Devices Skynax Push Messaging provides the mechanism through which applications can be remotely launched on a Windows Mobile device and standard Skynax Client communication sessions can be initiated, on demand, from a host system. The Skynax system provides the software communications infrastructure to transmit and receive these push messages. The contents of each push message is determined by the needs of the host system from which the push message is sent. Note: The Apple Push Notification Service is used to send messages to Apple mobile devices. For a visual diagram of this process, see the illustration Skynax Software Components with the Skynax MDM Service for ios on page 22. Host systems create push messages by inserting records into a special push message table within the Skynax Database. When the Skynax Client Push Message Service running on the target mobile device receives a push message, this message is made available to the mobile business application which then interprets the message and determines what action to take. For example, depending on the contents of the data in the push message, the mobile business application may connect to a Skynax Server for a specific Plug-In Process. It may use the message contents to update data in its database, or it may simply display a pop-up window with a message. In all cases, the creation and interpretation of push message data is entirely controlled by the host system and the recipient mobile business application. Skynax serves only as the secure platform through which system-wide push messages are transmitted. Skynax Mobility Management System Manual 31

42 Chapter 2 Skynax System Components The mobile business application still needs to interpret the message contents, call the Skynax Client to establish a connection to a Skynax Server, and request a specific Plug-In Process. When using the Intermec Data Management Solution for Skynax, data management can be initiated from the host system and fully automated for background operation on the mobile device. Note: Skynax push messaging requires that the target mobile device is connected to a network and its IP Address is directly reachable from a Skynax Gateway. If the mobile device is not connected, the message can still be delivered through client pull when the mobile device connects to a Skynax Gateway. Checkpoint Restart on Downloads The Skynax system can restart an interrupted file download at the point the download was interrupted. This download resume capability eliminates the need to retransmit previously downloaded portions of the same file. To resume the file download, the Skynax Client can connect to any Skynax Server that can access the file. Therefore, Intermec recommends that you store files to download to mobile devices in a host system location that is accessible by all Skynax Servers. To use this feature you must enable it in the Skynax system by turning it on in Skynax Manager. Note: The source file on the server-side does not need to be stored in the same location (such as a shared folder on a file server) to resume a file download, but the file must be identical at a binary level. Skynax automatically verifies that the source file used to resume download is identical to the one used during the previously download attempt. If Skynax determines that the file is not identical, Skynax assumes that the source file has changed (for example, the source file was overwritten by a new version of the file) and the file download automatically restarts at the beginning of the source file. 32 Skynax Mobility Management System Manual

43 Network Address Translation Chapter 2 Skynax System Components Skynax supports the automatic translation of IP Addresses in network topologies where mobile devices connect through a public network (such as the Internet, a GPRS, or APN) and need to access Skynax Gateways and Skynax Servers located within a private network, behind a firewall or router, that is using NAT (Network Address Translation). Using Skynax Manager, IP Address translation can be configured uniquely for each connection path and type of connection, such as GPRS, Wi-Fi, and LAN. Skynax supports Network Address Translation at the boundary between a private network containing the Skynax Gateway or Skynax Server applications and a public network within which mobile devices are running the Skynax Client. It is not possible to perform Network Address Translation between Skynax Gateways and Skynax Servers located in different networks - it is assumed that all Skynax Gateways and Skynax Servers are directly IP Addressable to each other within the private network (as they would be within a single LAN). Skynax Mobility Management System Manual 33

44 Chapter 2 Skynax System Components 34 Skynax Mobility Management System Manual

45 3 How to Implement a Skynax System You can implement different Skynax system topologies by installing Skynax software components in different combinations on multiple computers. Different topologies provide different Skynax system operating characteristics. The Skynax Setup Program allows you to designate the specific software components you want to install on each computer. 35

46 Chapter 3 How to Implement a Skynax System Implementation Overview Most organizations start the process of implementing a mobile computing system with a carefully planned pilot test. The pilot involves a limited number of future device users who test the mobile business applications and mobile computing devices selected by the organization. The purposes of the pilot test are to verify that the mobile computing system is working properly and to confirm the benefits of the mobile computing system. Skynax is designed to allow an organization to use a proven, costeffective mobile system management solution from the start of its mobile computing system implementation, and as needed, scale up quickly with an increasing number of mobile device users. Skynax grows with your organization, allowing for greater complexity as your business needs increase. Before you implement a Skynax system, you need to know the installation requirements for each computer and mobile device in your Skynax system. These requirements depend on the Skynax system topology you plan to implement. For more information, see the Skynax Mobility Management System Installation Guide. Skynax System Topologies The Skynax topology that you decide to use in your organization should take into consideration factors specific to your business and IT infrastructure, and as a result, may not be an exact replica of any one of these example topologies. It is worthwhile to note that even though Skynax provides many important, enterprise-level capabilities as a result of its ability to operate in a distributed manner, a distributed installation is not a requirement for running Skynax. In practice, many organizations begin by fully implementing Skynax on a single computer (a single server or PC workstation) and later move to a distributed implementation when they need to take advantage of some of the more advanced features of Skynax. 36 Skynax Mobility Management System Manual

47 Supported Topologies Chapter 3 How to Implement a Skynax System For small mobile computing systems, including even those with several hundred mobile device users, as well as implementations of Skynax for developers of Skynax-enabled mobile business applications, a single computer installation is typically sufficient. Clearly however, to work with Skynax features like load balancing and fail-over a minimum two computer installation is needed. Therefore, do not become overly concerned or anxious about the complexity of some of the advanced Skynax topologies illustrated on the following pages - from a practical standpoint, when you are just getting started with Skynax, you can comfortably skip over them. On the other hand, if your organization operates or plans to operate a large and complex mobile computing system then you should spend some extra time familiarizing yourself with the more advanced distributed Skynax topologies and underlying computing and networking infrastructure, if for no other reason than to be familiar with all the possibilities available to you when installing Skynax. When referring to a computer on which a Skynax software component is installed, it should be understood to mean any computer having sufficient processing power and other technical hardware parameters as specified for Skynax, which will enable it to satisfactorily run the selected Skynax software components. Therefore, when a computer is specified for a server-side component such as a Skynax Server and a Skynax Gateway, this does not mean you must use a computer that is designated as a server machine by its manufacturer but rather you can use any computer with the specified hardware requirements. For example, a single computer implementation of Skynax, can be performed such that all server-side software components of Skynax are installed on an appropriately configured desktop PC. The ability to install a Skynax system using different topologies is based on the Skynax software architecture. The Skynax architecture is comprised of software applications, like the Skynax Gateway, the Skynax Server and the Skynax Client, that can share and exchange information to create an integrated system for communications management, data management, and device management. You create different topologies by installing the individual server side Skynax Skynax Mobility Management System Manual 37

48 Chapter 3 How to Implement a Skynax System software components, namely the Skynax Gateway and Skynax Server, on multiple computers. And as long as each of these computers is connected to a network through which they can reliably access the Skynax Database, each computer can be geographically separated from the others installed at various locations around a manufacturing or distribution facility, or even at various locations around the country. The manner in which you decide to distribute Skynax software components to various computers at various locations in your IT infrastructure results in different Skynax system topologies and gives rise to different Skynax operating characteristics. When designing your specific Skynax system topology, you should focus on where you will install the server-side Skynax software components: Skynax Gateways Skynax Servers Skynax Plug-Ins Skynax Database Skynax Remote Assist Server whereas, it should be clear that the Skynax Clients are always distributed, in any topology, by the very nature that they reside on a mobile device. The other applications such as the Skynax Server Console and Skynax Manager are also installed on the server-side but these applications may be installed anywhere in the infrastructure without impacting the operating characteristics of the Skynax system. Note: Skynax is licensed in several different editions - only the Skynax Enterprise Edition supports a distributed topology. The Entry Edition and Standard Edition only allow for single computer installations of Skynax. About the Skynax Database The Skynax Database is always installed on only one computer, typically the computer on which the Microsoft SQL Server application is running. This means that Skynax supports only a single instance of the Skynax Database within each Skynax system. Therefore, in a single computer installation of Skynax where the computer is also running the SQL Server, the Skynax Database is 38 Skynax Mobility Management System Manual

49 Chapter 3 How to Implement a Skynax System installed directly on this computer. If however, the single computer installation of Skynax does not include an SQL Server running on the same computer but instead uses an SQL Server running on another computer in the network then the Skynax Database must first be installed on that remote SQL Server. The Skynax Gateway and Skynax Server must always be able to access the Skynax Database from each computer on which they are installed. The Skynax Database must always be accessible by the Skynax Gateway and Skynax Server. To minimize down-time, install the Skynax Database on an SQL Server with a hardware configuration designed to provide maximum fault-tolerance (through the use of hot-swap redundant parts or by using server clustering technology). You should also establish dual independent network access routes to the computer that the SQL Server is running on. About the Skynax Gateway and Skynax Server The Skynax Gateway and Skynax Server are standalone applications that run as services on the operating system of the computer. These applications are cooperative but not dependent. The Skynax Gateway and Skynax Server share and exchange information with each other whenever an instance of either application is available in a Skynax system, but both applications continue to operate if the other application is not available. This relationship allows you to implement a Skynax system topology that meets your performance and fault-tolerance needs. Note: If you have Apple ios devices in your Skynax system, you also need to install one Skynax MDM Service for ios. For more information, see the Skynax Mobility Management System Installation Guide. Skynax Mobility Management System Manual 39

50 Chapter 3 How to Implement a Skynax System About Skynax Plug-Ins A single Skynax system can have multiple Skynax Gateways and Skynax Servers. However, a single Skynax Gateway or Skynax Server cannot operate in multiple Skynax systems. To clarify this point, consider that a single instance of a Skynax Gateway is not able to function as a Skynax Gateway within two separate Skynax systems. Each Skynax system must have its own Skynax Gateways. This however, does not preclude having more than one Skynax system, perhaps using different topologies, running within one computer network. One computer can run only one instance of a Skynax Server and one instance of a Skynax Gateway at a time. For example, you cannot run two Skynax Gateways on the same computer, but you can run both a Skynax Server and a Skynax Gateway together on one computer. A Skynax system must have at least one running Skynax Gateway and one running Skynax Server. If the Skynax system includes Apple ios mobile devices, you also need one running Skynax MDM Service for ios. If the last Skynax Gateway or Skynax Server in a Skynax system fails, no further data communications are processed by Skynax until the problem with the Skynax Gateway computer or Skynax Server computer is resolved. To allow information exchange between different computers running a Skynax Gateway or Skynax Server application, these computers must be visible to each other across the network at the level of the TCP/IP protocol. For more information about Skynax open port requirements, see How to Work with TCP/ UDP Ports in Skynax on page 92. The Plug-In programs included with each Skynax-enabled mobile application can be run on any computer on which a Skynax Server is installed. In a single computer installation of Skynax, the Plug-Ins are run on the same computer. In a multi-computer Skynax Server installation the Plug-Ins can be run on any of the computers running a Skynax Server. 40 Skynax Mobility Management System Manual

51 Chapter 3 How to Implement a Skynax System For a Plug-In to run on any specific Skynax Server, you must first load the Plug-In into Skynax Manager, assign at least one of its processes to that Skynax Server and if that process has any required properties then those properties must be appropriately configured so that the process can run correctly. To decide which Plug-In processes to run on which Skynax Server computer, note these considerations: To provide a basic level of fault-tolerance, assign each Plug-In process to more than one Skynax Server computer. Assign complex Plug-In processes, which are processor or memory intensive, to Skynax Server computers that provide adequate processing power and memory to execute the instructions of the Plug-In programs at the desired speed. The processor and memory demands of any other applications already running on a Skynax Server computer (for example, if the Skynax Server computer is also used to run the Microsoft SQL Server application for access to the Skynax Database), impacts the speed of the computer and the number and types of additional Plug-In processes that may be executed simultaneously. If a Plug-In process interacts with an external data source or application (such as an SQL Database or an ERP application), the Plug-In must be able to reach the data source or application from the Skynax Server computer on which it is installed. If a Plug-In process interacts with an external data source that must be accessed at a remote location, it can be beneficial to have the Skynax Server computer, running that Plug-In process, also physically located close to that data source to avoid increased bandwidth utilization over WAN connections. If a particular Plug-In process is time sensitive (such as a Plug-In process that handles on-line credit checks by GPRS for a sales person selling and delivering products in the field), assign the Plug-In process to a dedicated Skynax Server computer to assure that the Plug-In receives maximum computer resources during peak loads so that it executes at high speed. Skynax Mobility Management System Manual 41

52 Chapter 3 How to Implement a Skynax System The balancing method used to control the processing load of individual Skynax Server computers in a Skynax system can be optimized by modifying the properties of each Skynax Server, as well as selecting the preferred load distribution strategy. These settings are all controlled using Skynax Manager. Consider any recommendations or requirements specified by the mobile application developer and Plug-In. Sample Skynax System Topologies Most Skynax system topologies are a variation of one these types of topologies: Single computer installation Dual computer installation with basic redundancy Multi-computer installation with load balancing and fail-over Multi-computer installation with mandatory Skynax Servers These examples illustrate the various possible Skynax system topologies and are provided as a starting point to help you structure the topology to implement Skynax in your organization. If you are just learning about Skynax or need to install Skynax to test Skynax-enabled mobile business applications, start with a single computer installation. You can always add an additional computer to extend your current topology with a Skynax Gateway or Skynax Server as needed, without shutting down the entire Skynax system or losing any configuration settings. Single Computer Installation The single computer installation of Skynax is the easiest and fastest to perform. It is also the least costly to implement, because it assumes that only one computer will be used to install and run all server-side Skynax software components. It is therefore, the preferred initial implementation scenario for most organizations and mobile application software developers. 42 Skynax Mobility Management System Manual

53 Chapter 3 How to Implement a Skynax System Even if you start with a single computer implementation, you can use all the core features of Skynax, including full communications management, device management, remote deployment of software packages to mobile devices, mobile device authentication, data compression and encryption, and mobile computing system monitoring. However, by the very nature of a single computer installation, it is not possible to use some of the Skynax advanced capabilities such as the load balancing of communications and data management processes as well as active fail-over to maximize mobile computing system up-time. Nevertheless, since Skynax is extendable in its topology, you can add and remove computers with Skynax software components later, as needed. The single computer installation of Skynax has a basic, straightforward structure, which is one computer where all Skynax server-side applications are installed. The Skynax Database may also be installed on the same computer or on another computer running Microsoft SQL Server. This installation is typically performed when an organization already has an SQL Server installed and does not want to run an additional instance of the SQL Server application for Skynax. Note: One computer can run only one instance of a Skynax Server and one instance of a Skynax Gateway at a time. For example, you cannot run two Skynax Gateways on the same computer, but you run both a Skynax Server and a Skynax Gateway together on one computer. A Skynax system running on a single computer does not support these features: Fault-Tolerant Authentication Fault-Tolerant SQL Server Access Load Balancing Active Fail-Over Skynax Mobility Management System Manual 43

54 Chapter 3 How to Implement a Skynax System A: Skynax System with Local Skynax Database Skynax Component Skynax Gateway Skynax Server and Plug-Ins Skynax MDM Service for ios (Apple ios) Skynax Database Technical Requirements Requires only 1 computer to host and run all server-side Skynax components. B: Skynax System with Remote Skynax Database Skynax Component Skynax Gateway Skynax Server & Plug-Ins Skynax MDM Service for ios (Apple ios) Skynax Database Technical Requirements Requires 1 computer to host and run the Skynax Gateway and Skynax Server applications. An additional computer running Microsoft SQL Server is needed. The Skynax Database may also be installed on an existing shared SQL Server. 44 Skynax Mobility Management System Manual

55 Chapter 3 How to Implement a Skynax System CORE INFRASTRUCTURE Host System Central Business Application Skynax Gateway Skynax Server Server Plug-In A Server Plug-In B LAN Microsoft SQL Server Skynax Database Skynax Management Applications Network Infrastructure (GPRS, CDMA, Ethernet, Wi-Fi, ) Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application REMOTE OFFICE 1 IN-FIELD / HOME OFFICE REMOTE OFFICE (n) Diagram of a Single Computer Installation This diagram illustrates a single computer installation of Skynax with the Skynax Database installed on the same computer as all other server-side Skynax software components. This single, networkattached computer is shown as part of the core server-side infrastructure. All Skynax Clients running on mobile devices connect to the Skynax Gateway or Skynax Server running on this central computer using wide-area and local area networks. Skynax Server Plug-Ins can also use the network to access and exchange data with host systems that may be running in the organization, such as an ERP system. You can also install Skynax Manager on any number of network attached desktop or notebook computers to monitor and configure the Skynax system. Skynax Mobility Management System Manual 45

56 Chapter 3 How to Implement a Skynax System The host system computer depicted in the core infrastructure of the diagram is only intended to illustrate some of the other host business applications that may exist within an organization, such as an ERP system, data warehouse, or call center and with which a Skynax Plug- In process may be designed to exchange data. Aside from the load balancing and active fail-over capabilities that are not supported in the single computer installation of Skynax, you should also take into consideration that a single computer installation limits the scalability of Skynax in terms of the number of mobile device users that can simultaneously be handled from a communications and data management perspective. The extent to which this will be a practical limitation in your implementation depends not only on the number of mobile devices that will be communicating at one time but also the complexity and number of Plug-In processes that will be running on the Skynax Server, and the processing power and memory of the computer on which the Skynax Server is installed. You should also be aware that in this single computer installation you will not be able to shut down any part of Skynax, for example to perform maintenance on the computer, without interrupting all Skynax services to mobile device users. Dual Computer Installation with Basic Redundancy This Skynax system topology uses two computers to run all the serverside Skynax software components. Typically, this installation topology would specify that a Skynax Gateway and Skynax Server be installed on each of the two computers, together with a full complement of all the required Plug-In processes. By using two computers in this topology, with a mirror installation of Skynax software, we are able to provide each mobile device with the option to authenticate against either of the two Skynax Gateways and then perform an exchange of data using the requested Plug-In process on either of the two Skynax Servers. This topology has an advantage over the single computer installation (as described in the prior example) by providing the benefit of greater fault tolerance. In practice, this type of dual computer installation would help prevent the interruption of Skynax services to mobile device users, in the event one of the computers running Skynax software would fail. This basic 46 Skynax Mobility Management System Manual

57 Chapter 3 How to Implement a Skynax System redundancy has proven useful in Skynax installations by allowing, in the event of a computer failure, Skynax services to continue to operate without requiring any immediate intervention by IT support staff, thereby extending the time-window available for correcting the problem on the failed computer. The downside of this Skynax system topology (and other multicomputer topologies) is that it increases the required investment in computers. However, as discussed earlier, this topology provides the benefit of greater fault tolerance for the mobile computing system through the use of distributed server-side Skynax software components and also provides for greater scalability by allowing the peak communications and data processing load to be spread between two computers. This topology is best suited for mid-sized mobile computing systems - typically those needing to improve connection scalability and Plug-In processing capacity, as well as requiring less susceptibility to interruption of mobile communications services due to a single computer failure. Skynax System with Remote Skynax Database Skynax Component Skynax Gateway Skynax Server & Plug-Ins Skynax MDM Service for ios (Apple ios) Skynax Database Technical Requirements Requires 2 computers, both of which will host and run the Skynax Gateway and Skynax Server applications as well as a full complement of all Plug-In processes. An additional computer running Microsoft SQL Server is needed. The Skynax Database may also be installed on an existing shared SQL Server. Skynax Mobility Management System Manual 47

58 Chapter 3 How to Implement a Skynax System Summary of Dual Computer Skynax Operating Features Supported by Topology Feature Yes Fault-Tolerant Authentication No 1 Fault-Tolerant SQL Server Access Yes - basic 2 Load Balancing Partial 3 Active Fail-Over 1 Provided the computer running SQL Server is not configured with redundant hardware components or operating in cluster mode, the loss of access to the Skynax Database precludes continued normal operation of Skynax. 2 Load balancing is only available for processes in Plug-Ins that are assigned to two or more computers in a Skynax system. In this dual-computer example, full redundancy is provided by assigning all Plug-In processes to both computers. 3 Active Fail-Over is provided as a function of the Skynax Gateway. However, in this dual-computer example, if one computer fails, any new device connections cannot be actively rerouted to another Skynax Server computer Instead, the Skynax Client running on the mobile device determines that the first computer is not available and automatically attempts to reconnect to the other computer. 48 Skynax Mobility Management System Manual

59 Chapter 3 How to Implement a Skynax System CORE INFRASTRUCTURE Host System Central Business Application 1 Host System Central Business Application (x) LAN Skynax Gateway 1 Skynax Server 1 Server Plug-In A Server Plug-In B Skynax Gateway 2 Skynax Server 2 Server Plug-In A Server Plug-In B Microsoft SQL Server Skynax Database Skynax Management Applications Network Infrastructure (GPRS, CDMA, Ethernet, Wi-Fi, ) Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application REMOTE OFFICE 1 IN-FIELD / HOME OFFICE REMOTE OFFICE (n) Dual Computer Installation with Basic Redundancy This diagram illustrates a dual computer installation of Skynax. Note the use of two computers, each running a Skynax Gateway and a Skynax Server. The other characteristics of this topology remain the same as in a single computer installation. Multi-Computer Installation with Load Balancing and Fail-Over This Skynax system topology uses multiple computers to run all the server-side Skynax software components. The computers may be physically located together such as when they are installed in a server rack or they may be geographically separated from each other such as when installed at various locations around a campus. In this type of topology the total number of computers running Skynax Gateways Skynax Mobility Management System Manual 49

60 Chapter 3 How to Implement a Skynax System and Skynax Servers is limited only by your Skynax digital license key. By installing and running Skynax Gateways and Skynax Servers on multiple geographically distributed computers you not only take advantage of increasing scalability but you also enhance the faulttolerance of your Skynax system. In this example topology, we have selected to install the Skynax Database on a clustered-computer configuration that is running SQL Server - this type of computer configuration provides increased protection against an isolated fault on an SQL Server computer. In business critical mobile computing systems special consideration should be given to the computer where the Skynax Database is installed - access to the Skynax Database is a requirement for proper operation of the Skynax system. For the same reason, it is prudent to implement backup and restore procedures for the Skynax Database to preclude the loss of Skynax related configuration and log transaction data in the event of any unforeseen problem. This advanced Skynax topology is particularly well suited for enterprise mobile computing systems. These mobile computing systems typically need extensive scalability to meet the needs of thousands of mobile device users as well as substantial capacity for running complex Plug-In processes together with a high level of system fault tolerance. Skynax System with Remote Skynax Database Skynax Component Skynax Gateway Skynax Server & Plug-Ins Skynax Database Technical Requirements Requires 2 or more computers, each hosting and running the Skynax Gateway. Requires 2 or more computers, each hosting and running the Skynax Server and a full complement of all Plug-In processes. Requires a fault-tolerant configuration for the computer that is hosting and running the Microsoft SQL Server. An additional computer running Microsoft SQL Server is needed. The Skynax Database may also be installed on an existing shared SQL Server. 50 Skynax Mobility Management System Manual

61 Chapter 3 How to Implement a Skynax System Summary of Multi-Computer Skynax Operating Features Supported by Topology Feature Yes Fault-Tolerant Authentication Yes 1 Fault-Tolerant SQL Server Access Yes 2 Load Balancing Yes 3 Active Fail-Over 1 This topology assumes Microsoft SQL Server is installed on a faulttolerant computer. 2 Load balancing is only available for processes in Plug-Ins that are assigned to two or more computers. The multi-computer installation described in this example provides full redundancy by assigning all Plug-In processes to all computers running a Skynax Server. 3 Active Fail-Over is provided as a function of the Skynax Gateway. The Skynax Gateway continuously monitors the operation of all Skynax Servers in a Skynax system and automatically reroutes new process requests from Skynax Clients to only those Skynax Servers that are operating correctly. The diagram illustrates a multi-computer installation of Skynax. Two computers are running Skynax Gateways and two computers are running Skynax Servers with the respective Plug-In processes assigned. In this topology, the two Skynax Gateways provide dual access and authorization points to which a mobile device may connect and two Skynax Servers over which the data management load can be distributed (assuming that all Plug-In processes are assigned to both Skynax Servers). This topology further extends the scalability offered by the dual-computer installation discussed in the prior example as well as further enhancing the fault tolerance of the Skynax system. Furthermore, additional computers may be added as needed in the future to run additional Skynax Gateways and Skynax Servers. The other characteristics of this topology remain the same as in the dualcomputer installation. Skynax Mobility Management System Manual 51

62 Chapter 3 How to Implement a Skynax System CORE INFRASTRUCTURE Host System Central Business Application 1 Host System Central Business Application (x) LAN Skynax Server (n+1) Server Plug-In A Server Plug-In B Skynax Server (n+k) Server Plug-In A Server Plug-In B Microsoft SQL Server with Cluster Services Skynax Database Skynax Gateway 1 Skynax Gateway (j) Skynax Management Applications Network Infrastructure (GPRS, CDMA, Ethernet, Wi-Fi, ) Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application REMOTE OFFICE 1 IN-FIELD / HOME OFFICE REMOTE OFFICE (n) Multi-Computer Installation with Load Balancing and Fail-Over Multi-Computer Installation with Mandatory Skynax Servers This Skynax topology is essentially the same as the multi-computer installation in the previous example. The primary difference is the introduction of Mandatory Servers which are geographically distributed between a central location and several regional locations, as per the diagram on the following page. Mandatory Servers are nothing more than Skynax Servers to which mobile device users with specific System Codes have been assigned. System Codes are a type of identifier that can be submitted by the user of a mobile device to uniquely identify themselves or identify a particular set of data that they are requesting to receive. For example, System Codes may represent route numbers in a mobile computing system for DSD or specific workers in a field services operation. You can assign specific System Codes to specific Skynax Servers using Skynax Manager. By assigning a System Code to a specific Skynax Server you are 52 Skynax Mobility Management System Manual

63 Chapter 3 How to Implement a Skynax System instructing all Skynax Gateways to force the routing of process requests, from any Skynax Client that identifies itself with that given System Code, to a particular Skynax Server or group of Skynax Servers - thereby making them Mandatory Servers for the processing of data exchanges with a given mobile device user. The use of geographically distributed Mandatory Servers in a Skynax system topology has proven useful in business scenarios where specific Plug-In processing requires access to data that is physically located at a remote location, such as a regional office or depot. By installing Skynax Servers at these remote locations and configuring them in Skynax Manager to serve as Mandatory Servers, you can force selected groups of Skynax Clients to connect to select Skynax Servers. This will result in Skynax Clients from a particular geographic region, to have their process requests handled by Skynax Servers which are physically located closest to them, thereby decreasing the utilization of bandwidth in your organization's WAN connections. Note that Skynax Gateways may also be regionally distributed in this topology. Skynax Mobility Management System Manual 53

64 Chapter 3 How to Implement a Skynax System C ORE INFRASTRUC TURE Host System C entral Business Application 1 Host System C entral Business Application (x) LAN Skynax Server (n+1 ) Server Plug-In A Server Plug-In B Skynax Server (n+k) Server Plug-In A Server Plug-In B Microsoft SQL Server with C luster Services Skynax Database Skynax Gateway 1 Skynax G ateway (j) Skynax Management Applications Regional Host System Business Application 1 Network Infras truc ture (G PRS, C D MA, E thernet, Wi-Fi, ) Regional Host System Business Application (n) Skynax Server 1 Mandatory Assignment Server Plug-In A Server Plug-In C Skynax Server (n) Mandatory Assignment Server Plug-In A Server Plug-In D S kynax C lient Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application S kynax C lient Skynax Device Drivers Skynax Loader Business Application Skynax Client Skynax Device Drivers Skynax Loader Business Application REMOTE OFFIC E 1 IN-FIELD / HOME OFFIC E REMOTE OFFIC E (n) Multi-Computer Installation with Mandatory Skynax Servers The Skynax Servers, depicted with an exclamation mark in the previous diagram, are intended to illustrate the configuration of geographically distributed, regional Mandatory Servers in a Skynax system. The diagram assumes that specific process requests coming from regional Skynax Clients will be forced to the Mandatory Server in the same region for handling whereas other process requests may be handled by a Skynax Server located at the head office. 54 Skynax Mobility Management System Manual

65 4 How to Manage a Skynax System This chapter provides information about how to manage a mobile computing system, describes key device management concepts, and introduces specific Skynax terminology. 55

66 Chapter 4 How to Manage a Skynax System Device Management Supported Devices Device management consists of all the tasks that need to be performed to provision each device so that it is ready for work. Device provisioning typically includes tasks such as installing or upgrading the software that will run on each device, as well as configuring device settings so that each device will operate as required by the software that will be used on the device. Skynax addresses device management needs by providing administrators with an easy to use point-and-click interface through which device management tasks can be remotely executed and automated. Automated, remote device management as performed by Skynax leads to consistent execution of device provisioning tasks, making it easy to update device options and manage software deployments without the overhead and risks associated with developing custom device management scripts or the limitations of traditional device management software. Skynax manages the devices that are registered for use in a Skynax system. You can register a device for use in a Skynax system only if that Skynax system has installed in it the appropriate Skynax Device Driver for the type of device you are attempting to register. Skynax Device Drivers can be added or replaced in a Skynax system at any time by adding a new Skynax Device Driver in the Device Drivers module of Skynax Manager. The Device Drivers module in Skynax Manager is used to maintain information about all Skynax Device Drivers that are installed in a given Skynax system. Skynax Device Drivers are available from the Intermec INsider website at 56 Skynax Mobility Management System Manual

67 Inside a Skynax Device Driver Chapter 4 How to Manage a Skynax System Each Skynax Device Driver is published as a collection of two files, both of which are required to successfully add or replace a Skynax Device Driver in a Skynax system. To install a Skynax Device Driver both of these files must be located in the same directory folder and this folder must be accessible from within Skynax Manager: The first file in a Skynax Device Driver installation set has a LFI or LFX extension and is the information file used by Skynax Manager to determine how the Skynax Device Driver should be installed. LFI and LFX files contain the same information and serve the same purpose, however LFX files use an XML format that provides faster installation processing when a new Skynax Device Driver is added to a Skynax system. The second file has the same name as the information file, however with a DLP extension. The DLP file is a compressed package that contains the files needed to install the Skynax Device Driver on a primary device.) Primary and Subordinate Devices Skynax Device Drivers classify all the types of devices they support as either primary or subordinate. A primary device is the central computing device on which software is executed. Primary devices include any of these types of devices: industrial handheld computers, PDAs, tablet computers, notebook computers and even smart phones. Subordinate devices are those types of devices that do not directly execute software but are installed in or attached to the primary device to extend its capabilities. Subordinate types of devices include wired and wireless network adapters, modems, bar-code scanners, RFID readers, mobile printers, and similar peripherals, accessories and primary device options. In Skynax Manager, switch to the Supported Types of Devices tab in the lower pane of the Device Drivers module to see what types of devices are supported by each Skynax Device Driver installed in the Skynax system. Skynax Mobility Management System Manual 57

68 Chapter 4 How to Manage a Skynax System Device Properties Each Skynax Device Driver contains a list of device properties that it uses to get specific information from a device (to interrogate a device) or apply specific settings to a device (to configure a device). All device properties are classified as either shared or individual. When a device property is designated as shared, any modification to the value of this device property will be inherited by all device sets that use the same device set template in which the shared device property was modified. Device properties designated as individual will only be applied to the respective device within the single device set in which the individual device property was modified. To manage shared device properties in device set templates, switch Skynax Manager to the Shared Device Properties tab on the lower pane of the Device Set Templates module. To manage individual device properties in selected device sets, switch Skynax Manager to the Individual Device Properties tab on the lower pane of the Device Sets module. Note: The list of device properties that are exposed for use in Skynax Manager is determined by the contents of each installed Skynax Device Driver. The developer of each Skynax Device Driver predetermines what device properties to expose in Skynax Manager and how these properties can be used to set or get information from the type of device that the Skynax Device Driver was designed to support. 58 Skynax Mobility Management System Manual

69 Device Set Templates and Device Sets Chapter 4 How to Manage a Skynax System Skynax Manager allows you to create device set templates based on the types of devices supported in the Skynax system. Each device set template consists of one primary device and one or more subordinate devices. By modifying the values of shared device properties in the device set template you can establish device configuration settings that will be used by all device sets that share the same device set template. The device set template also controls business application deployment for mobile devices running Apple ios. For mobile devices running Windows Mobile or Android, this process is controlled by the deployment group. For more information, see System Codes in Deployment Groups on page 65. Device sets are created by selecting a device set template and adding to the device set those real types of devices that match the requirements of the selected device set template. A complete device set will continuously inherit all shared device properties as defined in its device set template and consistently apply those settings to the physical devices whenever they connect to a Skynax Server. Note: The use of device set templates greatly enhances the simplicity and efficiency of device management. Therefore, as a matter of best practice, a device set template should be created to represent each different combination of devices that will share common device settings. The administrator will then be able to modify shared device properties for each device set template and have those property values automatically applied to all devices sets assigned to use that template. Each device set template is essentially an empty framework that defines the types of devices that will be required in any device set that uses it and defines the shared device properties that all device sets inherit from the template. The device sets specify actual mobile devices while the device set templates only specify the types of devices in a device set. Skynax Mobility Management System Manual 59

70 Chapter 4 How to Manage a Skynax System Device Set Template: Intermec CN3 for Field Services Type of Device: Intermec CN3 Mobile Computer Operating System: Windows Mobile 6.1 Classification: primary device Requires OEM Code: yes Type of Device: Intermec CN3 Ethernet Adapter Classification: subordinate device Requires OEM Code: no Type of Device: Intermec CN3 GPRS Adapter Classification: subordinate device Requires OEM Code: no Device Set: SET001 Device: Intermec CN3 Mobile Computer OEM Code: Device Set: SET002 Device: Intermec CN3 Ethernet Adapter Device: Intermec CN3 GPRS Adapter Device: Intermec CN3 Mobile Computer OEM Code: Device: Intermec CN3 Ethernet Adapter Device: Intermec CN3 GPRS Adapter Device Set: SET003 Device: Intermec CN3 Mobile Computer OEM Code: Device: Intermec CN3 Ethernet Adapter Device: Intermec CN3 GPRS Adapter Device Set Template: Intermec CK61 for DSD Type of Device: Intermec CK61 Mobile Computer Operating System: Windows Mobile 5 Classification: primary device Requires OEM Code: yes Type of Device: Intermec CK61 Ethernet Adapter Classification: subordinate device Requires OEM Code: no Type of Device: Intermec CK61 WiFi Adapter Classification: subordinate device Requires OEM Code: no Device Set: SET004 Device: Intermec CK61 Mobile Computer OEM Code: Device Set: SET005 Device: Intermec CK61 Ethernet Adapter Device: Intermec CK61 WiFi Adapter Device: Intermec CK61 Mobile Computer OEM Code: Device: Intermec CK61 Ethernet Adapter Device: Intermec CK61 WiFi Adapter This illustration shows the relationship between device sets and the device set templates that the device sets are based on. 60 Skynax Mobility Management System Manual

71 How to Work with Device Properties Chapter 4 How to Manage a Skynax System Each device property is pre-classified in its related Skynax Device Driver as a shared or individual device property. You can change this device property classification directly in Skynax Manager while viewing either a shared or individual device property. Note: As a matter of best practice, use shared device properties as opposed to individual device properties whenever possible. Because shared device properties are managed through device set templates and not individually for each device set, they generally provide a more efficient and consistent method for managing device configuration settings. Notice that the complete list of device properties that are applied to configure any one specific device is the result of combining both the individual device properties that are directly associated with the device set and the shared device properties that each device set inherits from the device set template that is assigned to it. Skynax Mobility Management System Manual 61

72 Chapter 4 How to Manage a Skynax System Device Set Template: Intermec CN3 for Field Services Shared Device Properties: GPRS Access Point Name = ATTAPN32 Modem Name = Cellular Line Connection Name = Skynax GPRS Password = 23i6Pw13... Device Set: SET001 Individual Device Properties: IP Address = Device Set: SET002 Individual Device Properties: IP Address = Device: CN3 with OEM Code: Complete List of Device Properties: GPRS Access Point Name = ATTAPN32 Modem Name = Cellular Line Connection Name = Skynax GPRS Password = 23i6Pw13... IP Address = Device: CN3 with OEM Code: Complete List of Device Properties: GPRS Access Point Name = ATTAPN32 Modem Name = Cellular Line Connection Name = Skynax GPRS Password = 23i6Pw13... IP Address = John CN3 Paul CN3 This illustrations shows the relationship between the shared device properties that are managed as part of each device set template and the individual device properties that are managed as part of each device set. The examples below demonstrate the use of shared and individual device properties. 62 Skynax Mobility Management System Manual

73 Chapter 4 How to Manage a Skynax System Example 1 If we define device configuration settings for an Intermec CN3 mobile computer that uses a fixed IP address, rather than an IP address from a DHCP server, should we make the device property named IP Address a shared or individual device property in Skynax Manager? In this example we would make it an individual device property and set it individually for each device set, because it would make no sense for all device sets to inherit the same IP Address as a shared device property value from their device set template. Example 2 If we need to configure the same time zone for a group of Intermec CN70 devices located within the same geographic region, should we make the device property that sets this time zone on a device, a shared or individual device property in Skynax Manager? In this example it would be best to make the time zone a shared device property so that we can set it only once in the device set template used by all the device sets. Using a shared property avoids the extra work of configuring the time zone as an individual device property within each device set. Example 3 If we need to configure different time zone settings for two groups of Intermec CN70 devices located in two different geographic regions, how can we accomplish this using the time-zone as a shared device property? In this example we create two device set templates so that we can assign all the device sets in each region to the appropriate device set template. We can set the value of the time zone differently as a shared device property in each of the two device set templates. Using a shared device property allows each device set to inherit the correct time-zone setting from their assigned device set template. Skynax Mobility Management System Manual 63

74 Chapter 4 How to Manage a Skynax System About System Codes for Windows Mobile A System Code is a unique identifier for a mobile device user or a mobile device used in a specific role. System Codes allow device users to uniquely identify themselves within a Skynax system regardless of which device set they may presently be using. Note: In contrast to the System Code, the OEM Code which is automatically generated by the Skynax Client and submitted to a Skynax Gateway during remote device registration and also during authentication, is permanently bound to the primary device hardware that it is generated on. This also explains why the Skynax Gateway uses the OEM Code for device level authentication and the System Code for user level authentication (if desired, the System Code can be further supplemented with a System Code Password). How to Use System Codes in Skynax With Skynax Manager, administrators assign Systems Codes to: Deployment Groups to specify what business application software will be deployed to a device set. Connection Groups to specify what communication rules will be followed by a device set. Mandatory Server Groups to optionally specify which Skynax Servers will handle process requests coming from a device set. Remote Assist Operator Groups to specify which group of remote assist operators will receive in coming support requests from a device set. In addition, a System Code may be used by a Plug-In process to determine in real-time what business data should be exchanged with each device set. Since a System Code is not tied to any one device set, a device user can submit a System Code from any device set and have that device set provisioned correctly for the work they are expected to perform. This on-the-fly provisioning improves system management flexibility and efficiency by allowing device sets to be swapped between device users as needed while assuring that any device set presently being used is always properly provisioned for the work being done by its user. 64 Skynax Mobility Management System Manual

75 Chapter 4 How to Manage a Skynax System In the first case, the System Code personally identifies each field service employee within the Skynax system. In the second case, the System Code only identifies a route but not the specific person that serviced it. In both cases however, the System Code is used by a Skynax Server to provision a user s device set with the right software and business data needed to perform their work. System Codes in Deployment Groups Skynax Manager enforces the rule that each System Code must always be assigned to one and only one deployment group. Each deployment group has a unique name and specifies one type of business application. Each deployment group may contain more than one set of software packages that can be deployed to a mobile device to install and run the selected business application. Each set of software packages (base package and update packages) must have assigned to them the equipment set templates that represent those device sets that are compatible with the software in each package. Note: Allowing one business application to have multiple sets of software packages allows different compilations of essentially the same application to be deployed to the appropriate device sets based on the device set templates that contain the types of devices that are compatible with the software compilation in each package. Skynax Servers automatically determine which business application software packages to deploy to each device set based on the: deployment group of the submitted System Code. software packages using a device set template that corresponds to the device set from which the System Code was submitted. If no software packages compatible with the user's device set are found (meaning no packages have assigned to them the same device set template that is assigned to the user's device set) or if the user's device set, as presently specified in the Device Sets module of Skynax Manager, does not exactly match the structure of the device set template that is assigned to it then no business application packages will be deployed to the device set. This is a safety mechanism within Skynax that helps to assure that device sets (or incomplete device sets) do not have deployed to them software packages with which they are Skynax Mobility Management System Manual 65

76 Chapter 4 How to Manage a Skynax System not compatible. Deploying incompatible software to a device set may cause the primary device to report software installation and execution errors, and in the worst case even lock-up the primary device thereby precluding any further work with the device until it is cold booted to restore its default factory settings. Example A company called SouthWind Inc. operates a mobile computing system for two types of applications - one for direct to store deliveries and the other for field services. Each of these applications are packaged in two compilations: the first compiled to execute on a mobile device having a StrongARM processor and the other compiled to execute on a mobile device with an x86 compatible processor. In this example, Skynax would use the System Code submitted by each device user to determine, based on the deployment group to which the System Code is assigned, which business application - the one for direct to store deliveries or the one for field services - is intended for the given user. Notice however, that this information by itself is insufficient for Skynax to determine which specific package of the business application - the one compiled to execute on a StrongARM processor or the one compiled to execute on an x86 compatible processor - should be deployed to the user s device. To determine which is the appropriate package to be deployed, Skynax will determine which of the packages have assigned to them the same device set template that is assigned to the user's device set. Those packages will then be deployed to the user's device to install the intended business application. 66 Skynax Mobility Management System Manual

77 System Codes in Mandatory Server Groups Chapter 4 How to Manage a Skynax System The Skynax Enterprise Edition supports the distributed operation of Skynax Servers in a Skynax system. When a company's business data is also distributed across various geographic locations, the use of distributed Skynax Servers can provide additional communications and data management benefits. By installing Skynax Servers on highspeed local networks at each location where the company's business data is stored, it is possible to force selected processes to exchange business data between host systems and relevant mobile devices over the local area network thereby reducing bandwidth utilization on the company's wide-area network as well as minimizing the time required to complete communications. Example A company has its customer database stored at each depot and only one Skynax Server installed at their head office. In this scenario each mobile device that docks at the depot and requests the process that updates their customer data would cause the relevant Skynax Server Plug-In process to begin pulling that data from the depot database up to the Skynax Server over the WAN only to turn around and have that data sent back down through the WAN to the requesting mobile device. This movement of business data through the WAN would be unnecessary if a second Skynax Server was installed at the depot so that the exchange of business data between the customer database, Skynax Server and the mobile device could all take place through the depot LAN. To take advantage of this capability, you need to create Mandatory Server Groups in Skynax Manager. Each Mandatory Server Group will have assigned to it selected Skynax Servers and processes, as well as selected System Codes. When this is complete the logic used by Skynax Gateways to allocate incoming process requests to Skynax Servers will be constrained such that only those Skynax Severs and process assigned to the Mandatory Server Group to which the System Code also belongs, will be considered. By assigning to a single Mandatory Server Group the System Codes that are relevant for device users at a specific geographic location you can force those device users to exchange business data in selected processes with your designated Skynax Servers. Skynax Mobility Management System Manual 67

78 Chapter 4 How to Manage a Skynax System System Codes in Plug-In Processes Skynax allows the processes within a Plug-In to reference the System Code that has been submitted by the device user when the connection to the Skynax Server was established. This allows a process to include the System Code as a variable in its conditional data management logic thereby giving each process great flexibility in its execution. Example A company with a large field service workforce is organized by territory. In this case, the Plug-In process that downloads customers to the user s device can reference the System Code as a variable to select customers that are relevant for the service person s territory. Being able to reference a System Code is more efficient than downloading the entire customer database to each user s device. System Code Management Typically, a System Code is unique identifier already being used by the company, such as an Employee Number, Terminal ID, or Route Number. System Codes can be created and managed manually in the Systems Codes module of Skynax Manager or they can be managed directly by a host system using the Skynax System Code Integration Interface. The latter approach allows host systems which are already responsible for the management of company equivalent unique identifiers to also directly manage the System Codes used within Skynax and thereby avoid their additional manual administration through Skynax Manager. Example The System Code for a field service company may be the equivalent of the employee number they assign to each of their field service employees. The System Code for a transport and logistics company that uses many, often changing independent subcontractors to perform daily pickup and delivery tasks may be the equivalent of a route number that represents the pickup and delivery route assigned each day to a contractor. 68 Skynax Mobility Management System Manual

79 System Code Pairing Spare System Codes Chapter 4 How to Manage a Skynax System By default, multiple mobile devices in a Skynax system can concurrently use the same System Code. For example, a group of mobile devices in a warehouse may use the same System Code to access the same business data. But, if necessary, you can enable System Code Pairing to prevent a System Code from being used by more than one device at the same time. When a mobile device connects to a Skynax System, it provides its unique OEM Code and requests to use a specific System Code. If System Code Pairing is enabled, the Skynax System checks to see if the requested System Code is being used by another mobile device: If the requested System Code is available: and this is the first time the mobile device requested the System Code, the Skynax system creates a pairing record and allows communication between the mobile device and System Code. and this is not the first time the mobile device requested the System Code, the Skynax system updates the pairing record and allows communication between the mobile device and System Code. If the requested System Code is currently paired with another mobile device, the Skynax system denies the request. When System Code Pairing is enabled, you can unlock paired System Codes so that they can be paired with another mobile device. For example, if a malfunction occurs on a mobile device that is paired with a specific System Code, you can unlock the pairing record so that the replacement mobile device can use the System Code. If a mobile device is removed from the Skynax system, the related pairing record is deleted. The System Code that was paired with the device is automatically unlocked for use with other mobile devices. If a mobile device that is paired with a System Code malfunctions, you can unlock the System Code so that it can be used by a replacement mobile device. However, the mobile device that malfunctioned may contain valuable business data that needs to be processed. Skynax Mobility Management System Manual 69

80 Chapter 4 How to Manage a Skynax System Because the original System Code is now paired with the replacement device, you need another System Code to send data from the original mobile device. For this specific case, you can create a special System Code called Spare System Code. A Spare System code can be used by multiple mobile devices concurrently, even if System Code Pairing is enabled. Note: You designate a System Code as a standard or Spare System Code when you create it. This designation cannot be changed. Data from a repaired mobile device may be incomplete or damaged. You should compare this data to the data received from the replacement mobile device. To ensure data integrity, you can design specific Plug-Ins to process data from mobile devices that are using a Spare System Code. Note: If you need to use a Spare System Code on multiple mobile devices at the same time, you need to take measures to be able to differentiate data uploaded by different mobile devices. System Code Management Typically, a System Code is a unique identifier already being used by the company, such as an Employee Number, Terminal ID, or Route Number. System Codes can be created and managed manually in the Systems Codes module of Skynax Manager or they can be managed directly by a host system using the Skynax System Code Integration Interface. The latter approach allows host systems which are already responsible for the management of company equivalent unique identifiers to also directly manage the System Codes used within Skynax and thereby avoid their additional manual administration through Skynax Manager. Example The System Code for a field service company may be the equivalent of the employee number they assign to each of their field service employees. The System Code for a transport and logistics company that uses many, often changing independent subcontractors to perform daily pickup and delivery tasks may be the equivalent of a route number that represents the pickup and delivery route assigned each day to a contractor. 70 Skynax Mobility Management System Manual

81 Chapter 4 How to Manage a Skynax System How to Deploy Software to Apple ios Devices Applications for Apple ios devices are distributed through the itunes App Store. Application distribution is controlled through the Device Set Template. How to Deploy Software to Windows Mobile and Android Devices Skynax Client Packages To deploy software to Windows Mobile or Android devices, you need to add the software to a package and use Skynax Manager to add the package to your Skynax system. Use Skynax Packager to create: Skynax Client packages for Windows Mobile or Android devices. Skynax Device Driver packages. Business Application packages for Windows Mobile or Android devices. A Skynax Client package contains all the files that comprise a specific version of the Skynax Client. This package is automatically be deployed to each device set in your Skynax system where its primary device uses the same operating system as that supported by the given Skynax Client. Skynax Device Driver Packages A Skynax Device Driver package contains all the files that comprise a specific version of a Skynax Device Driver. Each Skynax Device Driver supports a specific type of device hardware, exposes device properties that allow that type of device to be configured in Skynax Manager, and enables Skynax Client control of the device. This package is automatically deployed to each device set in your Skynax system if at least one of the types of devices in the device set matches the type of device supported by the Skynax Device Driver. Skynax Mobility Management System Manual 71

82 Chapter 4 How to Manage a Skynax System Business Application Packages A Business Application package contains files that are deployed to a device set to provision it with the mobile business application intended for the device user. These packages are typically created and customized for the specific mobile business application installation requirements of each customer. There are two types of Business Application packages: Base package: Contains all the necessary files to install a specific version of the mobile business application. Update package: Contains only files that need to be changed or added to the current installation of a mobile business application to update it. Update packages minimize the amount of data transmitted to device sets when you update the mobile business application. To re-provision the primary device in a device set, you need to deploy the base package and all update packages. If you delete the base package, all update packages are also deleted. You need to add a new base package to re-provision the primary device. Packages Deployed for Version 1.x.x Packages Deployed for Version 2.x.x Base Package ver Update Package ver Update Package ver Update Package ver Base Package ver Update Package ver Update Package ver t=0 t+1 t+2 t+3 t+4 t+5 t+6 t+7 time How to use a base package and update packages to manage the progressive deployment of business application software updates to mobile devices. Note: Skynax deploys packages to device sets in the order in which the packages are added to Skynax Manager. Package version numbers are only intended to be used for administrative purposes. 72 Skynax Mobility Management System Manual

83 Chapter 4 How to Manage a Skynax System When you delete a package from Skynax Manager, the package is not removed from the device sets that it is already installed on. Use one of these methods to return a device set to a previous state: Delete the package from Skynax Manager and re-provision the device set with Skynax Loader. Delete the base package from Skynax Manager and replace it with a new base package containing only the files you want to deploy. The next time the device connects, it detects the availability of a new base package and updates the device set with that package. Automated Business Application Package Deployments To allow mobile business applications to be deployed to any device set on-the-fly simply based on the System Code submitted by the device user, Skynax must be able to determine the availability of business application packages that are compatible with the device set that the device user is presently attempting to provision for work. Skynax accomplishes this by searching for all packages, in the same deployment group to which the System Code is assigned, that have assigned to them the same device set template that is used by the device set to be provisioned. In Skynax Manager, you configure the compatibility of base packages with device sets by assigning all the device set templates that represent device sets that have the types of devices that are compatible with the software in the package to each base package. Assigning device set templates to base packages with which corresponding device sets are not compatible can give unpredictable results when those packages are automatically deployed to the incompatible device sets. In a worst case scenario, the deployment of software to an incompatible device set can render that device set nonfunctional, leaving it unable to reconnect back to Skynax so that it can be re-provisioned. This diagram shows two sets of mobile devices (each based on their own device set template) and one deployment group for all System Codes but two different base packages for the same application. Each base package is assigned to a different device set template to designate the type of device with which each software package is compatible. Skynax Mobility Management System Manual 73

84 Chapter 4 How to Manage a Skynax System Primary Device in a Device Set Primary Device in a Device Set CN3 CN3 CN3 MC75 MC75 MC75 System Code: AGENT001 System Code: AGENT002 System Code: AGENT003 System Code: AGENT004 System Code: AGENT005 System Code: AGENT006 CN3 Mobile Computer with OEM Code: CN3 Mobile Computer with OEM Code: CN3 Mobile Computer with OEM Code: MC75 Mobile Computer with OEM Code: MC75 Mobile Computer with OEM Code: MC75 Mobile Computer with OEM Code: Device Set: SET001 Device Set: SET002 Device Set: SET003 Device Set: SET550 Device Set: SET551 Device Set: SET552 Device Set Template: Intermec CN3 for Field Services Business Application: Field Services Device Set Template: Motorola MC75 for Field Services Skynax System Configuration Base Package: FieldService_CN3.dlp Deployment Group: Field Service Applications (Assigned System Codes: AGENT001, AGENT002, AGENT003, AGENT004, AGENT005, AGENT006) Base Package: FieldService_MC75.dlp How Skynax determines which package is deployed to a mobile device In the previous diagram, if one of the device users (such as the one with a System Code of AGENT006 ) was to enter this System Code on a CN3 mobile computer as opposed to an MC75, this CN3 would be provisioned for their field service work using the appropriate software package for the CN3. The assignment of a System Code to a deployment group only specifies the business application that is intended for the device user ( Field Services in the previous diagram) but not which specific packages ( FieldService_CN3.dlp or FieldService_MC75.dlp in the previous diagram) will be deployed to the user s device. Which business application package should be deployed to the device that the device user is presently provisioning is determined implicitly by Skynax based on the device set templates that you assign to each base package. 74 Skynax Mobility Management System Manual

85 Chapter 4 How to Manage a Skynax System How to Update Mobile Business Applications for Windows Mobile or Android Devices Mobile business applications are designed to receive, process and output business data in accordance with the data structures and data processing rules developed for the business application. As a consequence these business applications have built-in dependencies with respect to what data they need and how that data is expected to be provided. Due to these data dependencies the process of updating mobile business applications can be complex and typically requires the coordinated execution of mobile device software updates with updates of host systems and their data integration interfaces. Skynax is designed to help make the entire process of updating mobile business applications easier, faster, more flexible and with less risk. One of the fundamental features that make this possible is the use of version controlled Plug-In processes that are requested as needed by the mobile business application. By specifying not only the process that is being requested but also its version, the mobile business application is able to connect to and exchange business data with those processes that are compatible with its data dependencies. When the mobile business application is updated in such a way that its data dependencies change then the developer of the mobile business application will include in the updated application logic the new version number of the process with which it is now compatible. Because each mobile business application will request only those process versions with which it is compatible, you can deploy and maintain within one mobile computing system, different versions of the same mobile business application without compromising the integrity of your host system data integration interfaces. The ability to operate multiple versions of the same mobile business application at the same time allows you to simplify new mobile business application deployment processes, avoid tedious and costly communication synchronization planning for the update process, and also offers unique advantages in software piloting and phased software rollouts. Skynax Mobility Management System Manual 75

86 Chapter 4 How to Manage a Skynax System Business Data Business Data Business Data Business Data Plug-In: MyData Process No: 4010 Process Version: 1.0 Host System Data Integration Interface Skynax Server Business Data Business Data Plug-In: MyData Process No: 4010 Process Version: 2.0 Business Data Business Data Skynax Client Mobile Business Application version 1.0 requests process: No and Version 1.0 Skynax Client Mobile Business Application version 1.2 requests process: No and Version 2.0 Updating Mobile Business Applications To assure that updated mobile business applications will have access to their required process versions, it is advisable to first install and configure all new Plug-Ins and then add new business applications to the Business Applications module in Skynax Manager. 76 Skynax Mobility Management System Manual

87 Chapter 4 How to Manage a Skynax System Register and Provision New Windows Mobile or Android Devices Before a mobile computer can connect to a Skynax system it must be registered for use in that Skynax system. Make sure that the mobile computer has a network connection and can reach the Skynax Gateway and Skynax Server. Note: The process to provision an Apple ios mobile device is similar. For help, see the Skynax Mobility Management System Installation Guide. 1 On the mobile computer, start the Skynax Loader application. 2 Tap Register. When the Skynax Gateway receives and accepts the authentication credentials for the mobile computer, a message appears indicating that the registration was successful. 3 After an administrator accepts your remote device registration in Skynax Manager (and assigns your newly registered device set to the appropriate device set template), connect to your Skynax system. Your mobile computer is automatically provisioned with the appropriate device settings and software. Re-Provision a Windows Mobile or Android Device When you cold boot a registered mobile computer or reset the factory default settings, you do not need to register the computer again. 1 On the mobile computer, start the Skynax Loader application. 2 Tap Connect. Skynax Mobility Management System Manual 77

88 Chapter 4 How to Manage a Skynax System How to Define Communication Rules for Windows Mobile and Android Devices Skynax allows you to manage communications between Windows Mobile or Android devices and host systems by grouping System Codes into Connection Groups. These groups are used to define the communication rules used by mobile devices to determine what type of network connection to open and which open network connection should be used to exchange different types of business data. Each Skynax system must have at least one connection group established before any mobile device communications can take place. Each connection group is comprised of one or more connection paths and a list of System Codes that have been selected and assigned to the group. The connection paths collectively define all the different types of network connections (such as LAN, Wi-Fi, GPRS, and CDMA) that the Skynax Client may open from the mobile device. Each connection path that you create will specify one type of network connection and the time period during which use of that type of connection is allowed. To each connection path you then assign those processes that may be requested to exchange business data over that type of connection. For each assigned process you can specify the priority with which that type of connection should be used. 78 Skynax Mobility Management System Manual

89 Chapter 4 How to Manage a Skynax System Defining Communications Rules By creating various connection groups with different connection paths and assigned processes you can establish different communication rules to meet the needs of different groups of device users. Each time you modify the parameters of a connection path or its assigned processes you are modifying the rules that will be used by the Skynax Client to manage mobile communications. Each device user will have their device provisioned with the communications rules specified by the connection group to which their submitted System Code is assigned. Automatic Selection of Connection Paths By default, the Skynax Client automatically selects the connection path to use each time the mobile business application requests a specific process. This automated selection process is based on the connection path rules defined by the administrator in Skynax Manager. Note: By configuring communication rules centrally and using the automatic selection of connection paths from each device based on the requested process, the administrator is able to establish and enforce least-cost connection routing rules that are in-line with business process objectives. Skynax Mobility Management System Manual 79

90 Chapter 4 How to Manage a Skynax System To determine which connection path should be used, for each requested process, the Skynax Client will first select all connection paths that the requested process may use. Next, the Skynax Client will check to see if any network connection is already open on the device. If a connection is already open then it will check to see if the requested process is allowed to use the open network connection. If an open network connection is of the type that can be used for the requested process, the Skynax Client will use it. If it is not one of the allowed types of network connections or no open network connection exists then the Skynax Client will step down the list of connection paths, in the order of their defined priorities, and attempt to establish a network connection that can be used for the requested process. If no network connection can be established (for example, if the device presently has no network connectivity options available to it) then the Skynax Client will report this event to the mobile business application as failure to connect. Manual Selection of Connection Paths In some business scenarios it may be beneficial to allow the automatic connection path selection process on the device to be overridden by the device user. In these scenarios the Skynax Client can always provide the mobile business application with a list of all the connection paths that may be used for its requested process. The mobile business application can display this list to the device user and use their input to select the type of network connection to use, regardless of the administrator s predefine connection path priorities. Note: Allowing the manual selection of connection paths typically makes most sense in cases where there exists many network connection options for each device, yet at any given time and location the device user knows that only one of the lower priority connection paths is feasible. In these cases the ability to jump directly to the use of that type of network connection can be faster than the automated connection path selection process which must discover the feasible connection by stepping through its connection path rules. 80 Skynax Mobility Management System Manual

91 Chapter 4 How to Manage a Skynax System To allow manual selection of connection paths the administrator must mark the check box in the Device User Can Change Priority field that is visible in the list of processes that may be requested through each connection path in the Connection Paths tab. This lower pane tab can be found in the Connection Groups module of Skynax Manager. Connection Paths Connection Path Priorities When a process is assigned to more than one connection path, the value entered in its Priority field determines the relative order in which the Skynax Client uses each connection path when the given process is requested by the mobile business application. The number entered for the connection path priority can be any positive integer value. Lower values have higher priority (a value of 1 is the highest priority, likewise a priority value of 50 will have higher priority than a value of 100 ). When assigning processes to a connection path, Skynax Manager automatically pre-assigns priority values which the administrator can later modify. Skynax Manager increments the priority value each time a process is assigned to an additional connection path thereby giving that connection path the lowest priority in the list of connection paths that may be used for the selected process. Therefore, assigning processes to connection paths in the order that you want them to be used by the Skynax Client will allow you to quickly complete your setup of connection paths. Skynax Mobility Management System Manual 81

92 Chapter 4 How to Manage a Skynax System To allow easy changes to be made in connection path priorities, you should use non-consecutive priority values (for example, avoid using 1,2,3,4 or 20, 21, 22 ). By using values with reasonable increments (for example, 10, 20, 30, 40 ) the administrator will have the future flexibility of entering a new priority for a new connection path such that it can logically come between two existing connection path priority values, without having to first modify the priorities of existing connection paths. Note: Each process, identified by its unique process number, has its own priority numbering sequence across all connection paths. For this reason you can expect to see two different processes, assigned to the same connection path, having the same priority value. The priority value is therefore significant for each process across all connection paths to which it is assigned but it has no meaning relative to the other processes assigned to any one connection path. Note: Skynax Manager enforces the rule that no two connection paths can have assigned to them a process with the same priority value (such a condition would otherwise result in an ambiguous connection path selection priority for the Skynax Client and is therefore not allowed). This will however, not prevent you from assigning the same process to two or more connection paths using different priorities or overlapping valid time periods for their use. How to Assign Processes to Connection Paths Every process that can be requested from a mobile device must be assigned to a connection path. All processes not assigned to a connection path will be unreachable. Therefore, to summarize, a process must be assigned to a Skynax Server, its respective Plug-In properties must be configured appropriately and the process must be assigned to a connection path in order for that process to be callable from the mobile device. The connection path to which the process is 82 Skynax Mobility Management System Manual

93 Chapter 4 How to Manage a Skynax System assigned must be one of the types of network connections that are supported by the mobile device from which the process may be requested. (For example, if the process is assigned to a GPRS based connection path then the user s device must have a supported GPRS adapter, otherwise the Skynax Client will determine that no connection path is presently available for the requested process.) Note: When you initially configure connection paths, start by assigning all processes to all connection paths so that they can be called through all network connections. This approach helps facilitate the initial testing and piloting of your system. After you confirm that everything is working correctly, you can start to remove processes that you want to exclude from using the selected type of network connection. If device users belonging to different Connection Groups are allowed to swap devices, assign all processes used by each Connection Group to the other group as well, so that both mobile business applications can call their required processes regardless of the device user. Assigning Processes to Connection Paths Skynax Mobility Management System Manual 83

94 Chapter 4 How to Manage a Skynax System Communication Rules Taking Effect The communication rules defined in Skynax Manager must first be updated on a mobile device before the Skynax Client on that device can interpret these rules and modify its communication management behavior accordingly. Communication rules are automatically updated on the device as needed, by a Skynax System Plug-In, each time the Skynax Client connects to a Skynax Server. Each device obtains those communication rules that relate to the connection group of which the submitted System Code is a member. The length of time required to deploy new communication rules within a mobile computing system varies primarily based on the type of connectivity available to all the devices and the presently established frequency of device communications. How to Work with Connection Paths To help clarify the setup of connection paths and how you can use various connection path configurations to manage mobile system communications, consider the following examples. Example 1 Assume that within a Skynax system we have assigned process number 6921 to a connection path based on GPRS with a priority of 1 during the time period from 6:00 to 18:00, and to a connection path based on LAN with a priority of 2 over the full 24 hour period, and finally to a third connection path again for GPRS but with a priority of 3 during the full 24 hour period. Question: In this scenario, during the time period from 6:00 to 18:00 what will be the Skynax Client s automatic connection path selection order when process 6921 is requested by a mobile business application? Answer: When process number 6921 is requested during the time period from 6:00 to 18:00 the Skynax Client attempts to use these network connections in the order shown: GPRS, LAN, GPRS. At all other times, the Skynax Client will first try to use LAN and then GPRS. 84 Skynax Mobility Management System Manual

95 Chapter 4 How to Manage a Skynax System Example 2 Assume that within a Skynax system we have installed and configured the Plug-In processes shown in the table below. Furthermore, assume that these processes are assigned to the connection paths as shown in the table below, and are being requested by device users with System Codes that are members of the connection group for which the communication rules applicable in this example are defined. Implicit is also the assumption that the device being used supports the type of network connectivity shown. Process Number and Process Descriptions Process Number and Process Description Process Number: 1010 Download Customer File Process Number: 1020 Download Full Price List Process Number: 1030 Download Stock Status Process Number: 2010 Upload Customer Orders Priority for Connection Path based on LAN Priority for Connection Path based on GPRS 10 not defined Given this information, consider these scenarios and questions: Question #1: If the mobile business application requests process number 1010 while the mobile device is out of its docking station (no LAN connectivity available), what happens? Answer #1: The Skynax Client determines that the only connection path that may be used is based on LAN and this type of network connectivity is presently unavailable to the device. As a result, the Skynax Client returns an error message to the mobile business application indicating that no connection can presently be established for the requested process. Skynax Mobility Management System Manual 85

96 Chapter 4 How to Manage a Skynax System Question #2: If the mobile business application requests process number 1020 and no other connections are presently open by the Skynax Client, what will happen? Answer #2: The Skynax Client determines, based on its locally stored communication rules, that the requested process can be handled through two connection paths, specifically one based on LAN and the other on GPRS. Since no network connections are presently open from the device the Skynax Client will step through the connection paths in the order of their defined priority. In this case, the Skynax Client will first attempt to establish a LAN based connection. If this fails then the Skynax Client will automatically attempt to establish a GPRS connection. Only in the event that neither of the network connections can be established will the Skynax Client report an error to the mobile business application. Question #3: If the mobile business application requests process number 2010 while the Skynax Client already has an open GPRS connection through which it is handling process number 1030, what will happen? Answer #3: The Skynax Client determines, based on its locally stored communication rules, that the requested process can be handled through two connection paths, specifically one based on LAN and the other on GPRS. Because the Skynax Client already has a GPRS network connection open and this type of network connection may also be used to handle process number 2010, the Skynax Client uses the open GPRS connection for this newly requested process as well. Note that in this case the Skynax Client will ignore the connection path priorities when determining the type of connection to use for process 2010, since an open network connection that is valid for the given process always takes precedence. (The Skynax Client gives precedence to the use of an open network connection as opposed to closing it and reopening a new network connection, because typically connection initiation incurs more overhead than is justified by the cost saving achieved by switching to a lower cost, higher priority network to handle most processes.) 86 Skynax Mobility Management System Manual

97 Connection Path Processing Chapter 4 How to Manage a Skynax System The next diagram depicts a practical example of the use of connection path processing rules in a Skynax system. The left and right sides of the diagram depict the valid connection paths and their priority during two different times of the day. The first time interval (depicted on the left side of the diagram) shows that if process number 1 is requested and connection path 1 is available, the Skynax Client uses connection path 1, because it is set as the highest priority for process number 1. If, during the time that connection path 1 is open the Skynax Client obtains a request for process number 2, this process also uses connection path 1 even though it is set as a lower priority than connection path 2. This is because connection path 1 is not only valid for process number 2 but it is already open. Furthermore, if the Skynax Client obtains a request for process number 3, it uses connection path 3, even if connection path 1 is still open, because only connection path 3 is valid for process number 3. Likewise, in the second time interval (depicted on the right side of the diagram) if the Skynax Client obtains a request for process number 1, it uses connection path I. If the Skynax Client obtains a request for process number 2, it uses connection path II, even if connection path I is already open, because connection path I is not valid for process number 2 during this time of the day. Skynax Mobility Management System Manual 87

98 Chapter 4 How to Manage a Skynax System Current Time: 07:00 pm Current Time: 01:00 pm Plug-In Process # 1 Plug-In Process # 2 Plug-In Process # 3 Plug-In Process # 1 Plug-In Process # 2 Plug-In Process # 3 Skynax Server Skynax Server Connection Path 1 Connection Path 2 Connection Path 3 Connection Path I Connection Path II Connection Path III Skynax Client Skynax Client Request for Process # 1 Request for Process # 2 Request for Process # 3 Request for Process # 1 Request for Process # 2 Request for Process # 3 Mobile Business Application Mobile Business Application Settings of Connection Paths Settings of Connection Paths Process # 1: CP1 w/ Priority 1 CP2 w/ Priority 2 CP3 w/ Priority 3 Process # 2: CP2 w/ Priority 1 CP1 w/ Priority 2 Process # 3: CP3 w/ Priority 1 Process # 1: CP1 w/ Priority 1 CP2 w/ Priority 2 CP3 w/ Priority 3 Process # 2: CP2 w/ Priority 1 Process # 3: CP3 w/ Priority 1 between 2:00am and 11:00am only. 9:25 9:59 Process # 2 9:50 10:15 Process # 3 9:25 9:59 Process # 2 9:50 10:15 Process # 3 9:00 9:30 Process # 1 9:00 9:30 Process # 1 time time Connection Path Processing 88 Skynax Mobility Management System Manual

99 Chapter 4 How to Manage a Skynax System System Plug-In Processes and Connection Paths The producers of Skynax have reserved all process numbers starting with process number and higher for use by System Plug-In processes. These special processes are used to manage the exchange of configuration, status and operating information between Skynax Clients and Skynax Servers - they do not handle the exchange of any business data. In the reserved process number range, the process numbers to inclusive, are System Plug-In processes that may be assigned/ unassigned to selected connection paths. Processes with a process number starting with and higher are System Plug-In process that are automatically assigned to all connection paths (they cannot be unassigned by the administrator) and their properties are also automatically configured (the properties used by these processes are not modifiable). Some System Plug-In processes can be unassigned from selected connection paths to allow the administrator to optimize specific communication scenarios. For example, by removing from a GPRS based connection path the System Plug-In process that handles the deployment of new business applications to devices, the administrator can prevent large application updates from taking place over GPRS, and instead allow them to be handled over other lower-cost, higher bandwidth network connections (such as LAN or Wi-Fi). How to Route Connections in Public and Private Networks In some network topologies it is necessary to communicate between mobile devices in a public network and Skynax Gateways and Skynax Servers located within a private network. Typically, there is a router between the public network and the private network. This router often uses NAT (Network Address Translation). For Skynax to retain the advantages of its distributed architecture, it needs to be configured so that mobile devices can correctly locate and connect to the server-side Skynax infrastructure when moving between a company s public and private network. Skynax Mobility Management System Manual 89

100 Chapter 4 How to Manage a Skynax System When a Skynax Client connects to a Skynax Gateway from within a private network, the Skynax Gateway forwards the Skynax Client to a Skynax Server using the IP Address of the Skynax Server as it is known within the private network. However, if that Skynax Client is connecting to a Skynax Gateway from a public network, the Skynax Gateway cannot direct the Skynax Client to the Skynax Server, because the IP Address of the Skynax Server in the private network cannot be resolved in the public network. That is, the Skynax Client cannot find the Skynax Server it is being redirected to. To resolve this situation, you can: use Skynax Manager to configure the Skynax Client to use the Microsoft VPN Client, which provides an additional secure tunnel layer into your private network from the mobile device. configure Network Address Translation (NAT) in your Skynax system. Skynax Clients need to be provided with an external IP Address and TCP Port through which they can reach the Skynax Gateway(s) and Skynax Server(s) running in the internal network behind the router. GPRS APN Network Skynax Gateways Within the internal network Skynax Gateways use their internal IP Address for communications. Network Router using NAT Skynax Clients Routing Connections in Public and Private Networks Skynax Servers Within the internal network Skynax Servers use their internal IP Address for communications. Skynax can easily be configured to work with a router or firewall that is using NAT between the Skynax Gateways and Skynax Servers installed in your LAN and the mobile devices in your WWAN. Skynax support for NAT is setup using the Network IP Address Translation tab in the Connection Groups module. Using this tab you can define 90 Skynax Mobility Management System Manual

101 Chapter 4 How to Manage a Skynax System the External IP Address and Internal IP Address that will be used by each Skynax Gateway and Skynax Server in your Skynax system. Support for NAT is configured separately for each group in the Connection Groups module and individually for each type of network connectivity. Before configuring your Skynax system to support NAT it may be helpful to consider what types of network connectivity will be used by your mobile devices and which of these types of network connectivity will require that TCP/IP packets flow through a NAT enabled router. For example, support for NAT may only be needed when the Skynax Client is connecting from a mobile device through GPRS, that is, connecting from a public network to your private network. However, when the Skynax Client is connecting from a mobile device attached to your LAN then we would not expect to use NAT because all communications would most likely be taking place within the internal network. Network Address Translation Note: If all the Skynax Gateways and Skynax Servers are in an internal network and you need to access them from a public network using a specific type of network connectivity, you need to configure all your Skynax Gateways and Skynax Servers to use NAT. Skynax Mobility Management System Manual 91

102 Chapter 4 How to Manage a Skynax System Note: Skynax Clients immediately receive new NAT-enabled connection path settings, but it may take up to 15 minutes for the new NAT configurations to be sent to all the Skynax Gateways and Skynax Servers. If you need to force an immediate refresh of your new NAT configurations, shutdown and restart your Skynax Gateway and Skynax Server applications. How to Work with TCP/UDP Ports in Skynax Skynax uses its own range of TCP and UDP Ports for handling communications within the Skynax system. Each service within the Skynax system uses its own TCP/UDP Port and proprietary high-level protocol to provide specific data exchange services. To facilitate the implementation of Skynax within various networks, Skynax allows most TCP Ports that it uses to be redefined. TCP Ports Skynax Port Name Default TCP Port Description Main TCP Port for Skynax Servers Main TCP Port for Skynax Gateways Handled by each Skynax Server, this TCP Port is used by all Skynax Clients to exchange data with Plug-In processes running on a Skynax Server. This TCP Port is also used by the Skynax System Monitor to obtain information on the availability of the Skynax Server. Handled by each Skynax Gateway, this TCP Port is used by all Skynax Clients to exchange authentication credentials and obtain process forwarding information to a Skynax Server. This TCP Port is also used by the Skynax System Monitor to obtain information on the availability of the Skynax Gateway. 92 Skynax Mobility Management System Manual

103 Chapter 4 How to Manage a Skynax System TCP Ports (continued) Skynax Port Name Default TCP Port Description Service TCP Port Handled by each Skynax Gateway, this TCP Port is used by all Skynax Servers to report real-time information concerning their availability and performance. Registration TCP Port for device OEM Code Handled by a Skynax Gateway, this port is used to receive the OEM Code registration request from a Skynax Loader. Console TCP Port Handled by each Skynax Server, this TCP Port is used by the Skynax Server Console application to obtain real-time server processing information. Push Message TCP Port for Skynax Gateway Remote Assist Server TCP Port Push Message TCP Ports for Skynax Clients Skynax MDM Service for ios Handled by a Skynax Gateway, this TCP Port is used to receive IP Address updates from the Skynax Client Push Message Service running on mobile devices. Handled by the instance of Skynax Remote Assist Server, this TCP port is used to receive data from the Skynax Remote Assist Plug-In running on the Skynax Server. Handled by a Skynax Client, this pool of TCP ports is used by the Skynax Client Push Message Service running on a mobile device to receive push messages from a Skynax Gateway. Handled by the Skynax MDM Service for ios, this TCP port is used by Skynax Loader for Apple ios device provisioning. Skynax Mobility Management System Manual 93

104 Chapter 4 How to Manage a Skynax System TCP Ports (continued) Skynax Port Name Default TCP Port Description These ports must be opened on the firewall to permit inbound packets from mobile devices in an external network to reach Skynax Gateways and Skynax Servers in the internal network. You will also need to forward these ports to the computers running Skynax Gateways and Skynax Servers. These ports must be opened on the firewall to permit outbound packets to reach mobile devices in the external network. UDP Ports Skynax Port Name Default UDP Port Description Echo UDP Port for Skynax Gateways Registration UDP Port for device OEM Code Handled by each Skynax Gateway, this UDP Port is used by the Skynax Client to send a UDP echo packet to all known Skynax Gateways to determine which Skynax Gateway provides the fastest response time Handled by a Skynax Gateway, this port is used to receive the OEM Code registration request from a Skynax Loader. 94 Skynax Mobility Management System Manual

105 Chapter 4 How to Manage a Skynax System Skynax System Monitor Skynax Server Console Console TCP Port Service TCP Port Skynax Gateway Main TCP Port Registration TCP Port Main TCP Port Skynax Server Push Message TCP Port Echo UDP Port Registration UDP Port Network Push Message TCP Ports Skynax Client This illustration depicts the relationship between the TCP/UDP Ports and Skynax applications. The Service TCP Port defined for the Skynax Gateway and the Console TCP Port defined for the Skynax Server are two different TCP Ports that serve entirely different purposes. It is not possible to use the Skynax Server Console application to also connect to and monitor a Skynax Gateway through the Service TCP Port. Structure of Communications Connections Each Skynax Client is capable of initiating one connection with one Skynax Server at a time. Each connection is established using one of the Skynax supported connectivity options that the mobile device is capable of using, such as GPRS, Wi-Fi, and LAN. On the receiving side, each Skynax Server is capable of handling many connections from many different Skynax Clients at the same time. The maximum Skynax Mobility Management System Manual 95

106 Chapter 4 How to Manage a Skynax System number of connections that can be handled by any given Skynax Server is based primarily on the characteristics of the computer on which the Skynax Server is installed and the number and complexity of Plug-In processes assigned to that Skynax Server. The Skynax Server assigns each received connection a virtual identification number called a Channel ID which is used to identify that specific connection when providing information about it to a Skynax Server Console application. Therefore, a channel in the Skynax Server Console application is equivalent to a connection that is formed between a Skynax Client and the monitored Skynax Server. Each connection is further divided into sessions - each connection will contain one or more sessions. A session is a virtual connection that is encapsulated within the physical network connection formed between a Skynax Client and a Skynax Server. Each connection in a Skynax system is independent from any other connection, and likewise each session is independent from any other session sharing the same connection. Sessions within a connection are created automatically by the Skynax Client to handle the exchange of data between a Skynax Client and a Skynax Server for one specific process within a Plug-In. Each process number requested by a mobile business application via the Skynax Client will have its own dedicated session for the exchange of data - it may however share a single network connection with other sessions. Skynax Server Channel x Channel 2 Channel 1 Connection Session i Connection Skynax Client This illustration depicts the structure of a single connection formed between a Skynax Client and a Skynax Server. 96 Skynax Mobility Management System Manual

107 Chapter 4 How to Manage a Skynax System Mobile Business Applications for Windows Mobile and Android Devices Mobile business applications are an integral part of every mobile computing system solution. These applications run on the mobile device and provide users with the business level functions needed to perform their work, such as taking an order, issuing an invoicing, or documenting a service incident. These applications may be as simple or as complex as is warranted by the business processes they are designed to support. Skynax-enabled mobile business applications are designed to work together with the Skynax Client on the mobile device, thereby leveraging the device management, data management, communications management and communications security features that are an integral part of Skynax without having to custom develop and maintain this wide-scope of generic functionality, for each mobile computing system solution that is implemented. Skynax however, does not come bundled with any mobile business applications. Mobile business applications are available directly from Skynax Implementation Partners. Furthermore, Skynax Implementation Partners that offer their customers a Skynax-enabled mobile business application can provide a complete out-of-the-box solution with an outstanding range of endto-end mobile computing system management capabilities that compliment the business functionality of their mobile business application and enhance the total value of their solution. A special purpose Skynax Test Client application is available for use in the absence of a Skynax-enabled mobile business application. This application provides no business functionality, however it can be temporarily substituted for a mobile business application to test the communications management, data management and device management functionalities of Skynax within a customer-specific network environment. Skynax Mobility Management System Manual 97

108 Chapter 4 How to Manage a Skynax System To obtain a Skynax-enabled mobile business application please contact a Skynax Implementation Partner or contact us to be referred to Skynax Implementation Partners that specializes in providing the types of solutions you are seeking. Note: A mobile business application or simply business application refers to a general class of last-mile business software applications that are deployed to, and run on, a mobile device. 98 Skynax Mobility Management System Manual

109

110 by Honeywell th Avenue West Everett, Washington U.S.A. tel fax Intermec by Honeywell All rights reserved. Skynax Mobility Management System Manual * * P/N