Syclo ImplAdmin Guide

smart WorkManager5.0.
2
FOR SAPERP
ImplementationandAdministration
2ndEdition
1721 Moon Lake Boulevard | Suite 300 Hoffman Estates, IL 60169 800.567.9256 toll free - North America info@syclo.com | www.syclo.com Syclo International Limited | Europe, Middle East & Africa Fetcham Park House, Lower Road, Fetcham, Leatherhead, Surrey, KT22 9HD, United Kingdom +44 (0) 1372 371031 phone | +44 (0) 1372 371032 fax
This document is presented as is and as such no warranty, express or implied, is made by Syclo as to the accuracy and completeness of this document or related material, nor shall the fact of distribution of this document and the related material constitute any such warranty, and no such responsibility is assumed by Syclo in connection therewith. Information contained within is subject to change without notice. This work is protected by the copyright laws of the United States of America and is proprietary to Syclo, LLC. Disclosure, copying or reproduction, merger, translation, modification, enhancement or use by anyone other than authorized employees or licensees of Syclo, without prior express consent of Syclo, is strictly prohibited. Copyright 2011 Syclo, LLC. All Rights Reserved. Syclo and Agentry are trademarks of Syclo, LLC. SAP, SAP CRM and SAP ERP are registered trademarks of SAP AG in Germany and several other countries. All other products and logos are the trademarks or registered trademarks of their respective holders.
Contents
SMART Work Manager for SAP ERP System Architecture Overview 7
Work Manager Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Agentry Components for Product Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 Product Name Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 The Agentry Server in a Production Environment . . . . . . . . . . . . . . . . . . . . . . . .11 The Agentry Server in a Development Environment . . . . . . . . . . . . . . . . . . . . . .12 The Agentry Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 The Agentry Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 The Agentry Test Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Work Manager System Requirements 18
SMART Server System Requirements Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Virtualization Software Support for the Agentry Server . . . . . . . . . . . . . . . . . . . .20 Agentry Server Hardware Requirements 32-bit Windows Server . . . . . . . . . . . .21 Agentry Server Hardware Requirements 64-bit Windows Server . . . . . . . . . . . .22 Agentry Server Hardware Requirements 64-bit Linux Server . . . . . . . . . . . . . . .23 CentOS and Red Hat Linux System Requirements . . . . . . . . . . . . . . . . . . . . . . .24 Agentry Editor Hardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Agentry Editor Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Agentry Client Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 SMART Mobile Suite Administration Requirements . . . . . . . . . . . . . . . . . . . . . . . . .28 SMART Mobile Suite Administration Component Installation 29
SMART Mobile Suite Administration Component Installation Overview . . . . . . . . . .30 Installing SMART Mobile Suite Administration Component for SAP ERP . . . . .31 Preparation for Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Software Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 Post Installation - Required . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 Post Installation - Optional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Work Manager Server Installation 38
Install the Java SDK and JRE Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Installing the SMART Server For Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 Installing the SMART Server on CentOS 5.2 Linux. . . . . . . . . . . . . . . . . . . . . . . . . .48 Configuring the SMART Server to the SAP Systems Time Zone. . . . . . . . . . . . . . .51
Contents
Connecting SMART Server to a Distributed SAP Environment . . . . . . . . . . . . . . . . 52 Connecting the SMART Server to a Load Balanced SAP System . . . . . . . . . . . . . . 53 Testing Connectivity to SAP Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Additional JavaBe.ini Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Configuring Agentry Client-Server Communications . . . . . . . . . . . . . . . . . . . . . . . . 59 Installing the Agentry Editor 62
Installing the Agentry Editor Plug-In and Eclipse Platform . . . . . . . . . . . . . . . . . . . . 63 Importing a New Agentry Project Into the Eclipse Workspace . . . . . . . . . . . . . . . . . 70 Installing the Work Manager Client 74
Windows CE SMART Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Windows 32 SMART Client Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Security Features and Specifications 79
Web Application Security in Netweaver AS ABAP . . . . . . . . . . . . . . . . . . . . . . . . . . 80 SAP ERP Authorizations for Mobile Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Security Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Overview of Security Features in Agentry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Agentry Security Specifications Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Authentication Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating a Self Signed Certificate Using OpenSSL . . . . . . . . . . . . . . . . . . . . . . 87 Creating a Self Signed Certificate Using Microsoft's Certificate Creation Tool . . 88 Creating CA Certificate for Agentry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Work Manager Server Utilities 92
Overview of the Agentry Server Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Agentry Server Administration Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Connecting the Agentry GUI Agentry Administration Client . . . . . . . . . . . . . . . . 96 Using the Agentry GUI Agentry Administration Client. . . . . . . . . . . . . . . . . . . . . 98 Clustering Multiple Agentry Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Changing Configuration Settings with the Agentry Administration Clients . . . . 106 System and User Information in Agentry Administration Clients. . . . . . . . . . . . 108 Agentry Command Console Commands Reference . . . . . . . . . . . . . . . . . . . . . 110 Encrypt Password Utility Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Contents
Using the Encrypt Password Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113 Server Key Migration Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115 Server Key Migration Utility Command Line Reference. . . . . . . . . . . . . . . . . . .116 Exporting a Servers Private Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . .117 Importing a New Private Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118 Deleting a Servers Private Encryption Key . . . . . . . . . . . . . . . . . . . . . . . . . . . .119 Work Manager Server Log File Management 120
Agentry Server Logs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121 Events.log File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124 Messages.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .125 Startup.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129 Shutdown.log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130 Enabling Agentry Server Log Messages and Files . . . . . . . . . . . . . . . . . . . . . . . . .131 SMART Mobile Suite Administration Component Logs. . . . . . . . . . . . . . . . . . . . . .134 Work Manager Backup and Restore Information 136
Backing up the SMART Server on a Windows Host . . . . . . . . . . . . . . . . . . . . . . . .137 Backing up the SMART Client. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138 Backing up the SMART Mobile Suite Administration Component. . . . . . . . . . . . . .139 Installation Trouble Shooting 140
Verifying Version Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141 SMART Server to SAP Connection Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143 SMART Server to Client Connection Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . .144 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .146
SMART Work Manager for SAP ERP System Architecture Overview
Work Manager Overview

Work Manager is designed to automate workflow and improve service with mobile work orders, notifications and time management. Work Manager connects mobile employees with the data stored in an SAP system so they can better manage work and service requests.
Creating a Paperless Workflow

Work Manager enables specific details such as asset, customer, or transaction histories and other critical information to be delivered to employees using mobile devices such as PDAs, tablets or laptop computers. In turn, data is uploaded to an SAP system to generate follow-up work orders, status reports, customer invoices, charge backs and more. Figure 1: Work Manager Paperless Workflow
The paperless workflow process is as follows: 1) Workers log on to their mobile devices and download new work orders through a docking cradle or a real-time wireless connection. 2) Workers can then follow step-by-step job plans, verify work completed and work status, as well as access additional details of a work order or notification to improve decision-making. 3) Workers update customer accounts, place orders, transfer or reassign work to another team member, or complete all required information and update to the SAP backend system. This added data is accurate and usable, as Work Manager enforces business rules on the mobile device (i.e., not allowing modifications or edits of objects if not allowed by the backend) 4) Workers transmit their updated or added data to the backend for any additional processing.
Agentry Components for Product Name

Product Name is developed and deployed on Syclo's Agentry Mobile Platform. The Agentry Mobile Platform has three main software components: The Agentry Server The Agentry Editor The Agentry Client
The Product Name Server and Product Name Client are software components built on the Agentry Server and Agentry Client. The Agentry Mobile Platform consists of the Agentry Development Environment and Agentry Production Environment. The Agentry Editor is the primary development tool used to create and customize the Product Name application. The diagram below displays how the components of Product Name interact with each other and the Back End Name System.
10
Product Name Server

The Product Name Server is a communication hub within the Product Name application. The Server provides two-way communication between the Product Name application and the Back End Name database during synchronization. The information exchanged between these two systems is referred to as the production data of the Product Name application. The Product Name Server does not store any information internally, but rather manages all communications, synchronization, error handling, personalization and transactional controls needed for the mobile application to function. The Product Name Server also serves application data, or the data that provides the business logic and behavior to the Product Name Clients. When changes are made to the application in the Platform Editor, they are published to the Product Name Server. The Server transmits the changes to the Product Name Clients during their next synchronization. No special actions are required on the part of the users when new application data is received. For instance, the users do not need to restart the Client. In the Product Name Production Environment, multiple versions of the application are stored and supported by the Product Name Server at one time. This allows for older versions of the application running on the clients to still communicate with the server and receive the updates. The Product Name Server can be configured as a Development or Production Server. The functionality and behavior of each is similar in either configuration. However, the Development Server is intended for development work and the Production Server is intended for real-world production environments.
11
The Agentry Server in a Production Environment

The Agentry Server in a production environment, called the Agentry Production Server, exhibits the behaviors beneficial to large numbers of concurrent users synchronizing production data. It also is capable of maintaining multiple versions of the application to allow for incremental updates of application modifications to the Clients. To improve performance and minimize storage requirements, an Agentry Production Server does not generate most of the available log files by default. The run-time information it will log covers startup and shut down events, Client-Server messaging, and certain Server events. All other log files are disabled by default. They can be enabled when needed, but should not remain enabled longer than is necessary. The application data stored on the Server is managed in such a manner as to allow for an incremental upgrade of the application to the Clients when modifications are published from the Agentry Editor. Depending on information provided during the publish, the Server may process data changes received from a Client using the previous version of the application before sending the new version to that Client. It is also possible in a production publish to specify that changes published to the Server not be updated to the Clients until after a specified date and time. An instance of the Agentry Production Server should never be used for development work. This is primarily due to the number of times a publish is performed in a typical development life cycle. A Production Server keeps all versions of the application published to it and reads in all versions during startup. During development work the number of versions could quickly number in the dozens, which would in turn result in a long delay in starting a Production Server and significantly impact its overall performance.
12
The Agentry Server in a Development Environment

The Agentry Server in a development environment, called the Agentry Development Server, is intended for use during the development, configuration, and/or customization process. Frequent changes are made to the application and published to the development server for testing. The Agentry Development Server it is not intended for a large number of users. The behaviors exhibited by the Server in a development environment benefit a developer or implementor. An Agentry Development Server will store only one version of the application, with each new published version overwriting the previous version. This is for the sake of performance, as the Server reads in all versions of the application at startup. Since in a development environment dozens of changes may be made and published within a short time period, if different versions were kept, the total number stored on the Server could quickly become large and result in much longer startup times for the Server. These definitions are maintained as separate files. This structure allows for direct modification of any script or source files containing SQL, Java, or batch file commands. The previously published version of the application is not kept, but instead is overwritten by the new version. The resulting effect of this behavior is that Client-Server communications will always behave according to the latest version of the application. There is no version information stored with a development publish. An instance of the Agentry Development Server should never be used in a live production implementation. The configuration of a Development Server is such that performance is sacrificed for development-level information and behaviors. For this reason, the Agentry Development Server should only be implemented in a development environment for development or test users and back end systems.
13
The Agentry Editor

The Agentry Editor is the primary development tool used to create, test, and deploy a mobile application. It is also the tool used to configure or extend an application for a specific deployment. The Editor is a 4th-generation language tool (4GL), providing point and click development. Much of the lower-level code writing is removed from the development process via the usage of the Agentry Editor. The Agentry Editor is a component of the development environment. During development the application will be published from the Editor to an instance of the Agentry Development Server for development and unit testing. Once an application is finalized and ready for deployment, it will be published from the Editor to the Agentry Production Server. From here it will be deployed to the Clients during synchronization.
Eclipse Plug-In
The Agentry Editor is provided as a plug-in tool to the Eclipse platform. This architecture is beneficial to the developer or implementor in that it provides an industry standard interface, and also allows the Editor to leverage many of the powerful tools available within Eclipse. During installation, the Eclipse platform can be installed with the Editor, or the Editor plug-in can be installed to an existing Eclipse implementation. Eclipse provides built-in testing, debugging, and emulation capabilities. It also includes search functionality, import/export features, and the ability to visually modify screens.
Agentry Application Projects

The pieces of an Agentry application are called definitions. A developer creates or modifies these definitions to affect the behavior of the application. The definitions for applications are organized into projects, which are created and maintained within the Agentry Editor. The Editor itself presents these definitions according the application hierarchy within Agentry. This hierarchy is the logical structure of an application and dictates how the different definitions relate to one another. An Agentry application project is stored and managed within the Eclipse workspace. An existing application project can be imported from one workspace to another, creating a new Agentry application project within that workspace. Other components of the overall application solution, such as Java projects and related source code are also stored in this same workspace within Eclipse. This supports a more seamless overall structure to the mobile application and its related components.
Application Project Management

In addition to development work, the Agentry Editor provides tools to support management of the application project. These include the ability to export portions of an application from one project and to import those same pieces into another project. This can be useful when modularizing functionality for reuse in separate applications, and also when multiple developers are working on the same application. As a part of this import and export functionality are the abilities to visually compare two projects and to export the differences between two different versions of the same application.
14

Another significant functionality set for application and project management is Team Configuration. This functionality set was added to the system with the 5.2 release of Agentry. This new feature provides support for a shared repository of development work accessible to all developers on a team for the same application. This repository supports multiple revisions, and checkouts, commits, and updates to and from this common source. For full details on this functionality see the Agentry Development Guide for Agentry 5.2.
15
The Agentry Clients

The Agentry Client is the Agentry component installed to the client devices provided to the end users. This component of Agentry is the one that presents the interface of the application. There are numerous builds of the Client, each intended for a different type of client device. These include different versions of the mobile Windows operating systems, in combination with different device processors, and also in combination with certain device manufacturers. The Agentry Client provides certain built-in functionality that is exhibited regardless of the application it is running. Much of this includes built-in screens to provide a user interface for common functionality. For devices with added hardware capabilities, such as barcode scanners or GPS units, additional resources are installed with the Agentry Client executable to support the available functionality. An additional set of Client builds are those that provide client-side data encryption. This functionality encrypts all data, both production and application, stored on the client device by the Agentry Client. This is an optional build of the Client that may or may not be installed. The Agentry Client is capable of providing the user with the full functionality set available within the application whether it is connected to the Agentry Server or not. This ability to run and function in an off-line state means users will experience little or no work interruptions due to unavailable or spotty network access. The Client is capable of storing large amounts of production data, within the limitations of the client devices storage capacity, for use within the application.
16
The Agentry Test Environment

The Agentry Test Environment, or ATE, is a software component provided for developers and testers. It is used in both the development and production environments of Agentry. The ATE is used for development and unit testing and includes the standard Agentry Client wrapped within the ATE itself.
Mimicking Multiple Platforms

The ATE provides the developer or tester with the ability to mimic different supported client device platforms. This includes the display of the screens defined for a specific platform within the application project. The current platform is changed within the ATE and can be done at any time. The Client will be reset and a transmit is performed to retrieve the application as it appears on the new target platform.
Debugging Tools
The ATE provides debugging and data inspection tools. These tools can be very useful to a developer, as they expose the data stored on the Client as well as the complex business logic contained in the definitions at run time. During transmit the transmit dialog within the ATEs Client displays additional information in relation to any errors or issues that are not normally displayed in a standard Client. This information includes error messaging returned by the back end system. This can include error messages related to processing SQL statements, messages generated by the Java Runtime Environment, and other similar messaging. For client-side functionality, the ATE includes a robust set of debugging tools. These tools allow for the setting of break points within transaction processing, rule debugging and logging, data inspectors for objects, data tables, complex tables, and transactions. For testing of scanner platforms, the ATE includes the ability to pass values to the client through the scanner API, thus mimicking scanner functionality and allowing for the evaluation and testing of scanner behaviors and features. Similar behavior exists for GPS unit functionality. Location values can be passed to the client through the ATE, just as if provided by a client devices GPS unit. Other functionality related to testing includes the ability to fail network communications for a given transmit configuration. This is used to test defined transmit configuration failover behavior. The ATE also has uses in the Production Environment. Specifically, it can be used to diagnose an issue encountered in a deployed application. In addition to the inspection and debugging tools, the ATE can force the Agentry Production Server to produce the logging information that is otherwise disabled. This information will only be generated for a single transmission from the ATE, meaning the log files are not enabled for all users. This prevents unneeded log file messages from being generated and significantly reduces any impact on the Servers performance.
Test Script Recording and Playback

Another powerful feature of the ATE is the ability to record and play back test scripts. Using the test script functionality, the operations performed by a test user can be recorded in the ATE to an XML file that is an Agentry Test Script. This script can then be played back repeatedly to perform the exact same test operations multiple times. The test script language includes methodology for
17
querying database values, as well as the ability to provide test data to be passed into the test client. Recorded in the script are all button clicks, list selections, entered values, and any other actions performed by a user with the client. The ATE can then play back any Agentry Test Script that has been created.
Work Manager System Requirements
19
SMART Server System Requirements Overview

Before reviewing the hardware and software requirements for the SMART Server, it is first important to determine the intended host systems operating system. It is also necessary to have an understanding of the amount of data to be synchronized by a typical user, and finally to consider the functionality that may be provided within the mobile application.
Supported Operating Systems

The SMART Server is provided in multiple builds with separate installers. These installers are intended to install the Server to one or more of the Servers supported operating systems for the SMART application. When reviewing the software requirements, be sure to review the list of requirements provided for the operating system on which the SMART Server will be deployed for the implementation environment. For this version of SMART, the supported operating systems include the following: Windows XP Professional Development Server Installations Only Windows Server 2003 32-bit Windows Server 2003 64-bit Windows Server 2008 32-bit Windows Server 2008 64-bit CentOS 5.2 64-bit Red Hat Enterprise 5.2 64-bit
Functionality, Data and Resources

The functionality and the amount of data to be provided for a specific implementation of the SMART application can affect the resources required of the Servers host system. The following functional components and other factors can increase the amount of resources needed at a given implementation of the SMART application: Server Push. File Transfer/Attached Documents. Large complex tables, with record counts in the 10,000 to 100,000 range. Numerous complex table definitions, with the number of complex tables over 30. Complex tables with large numbers of fields per record, or a large number of indexes.
20
Virtualization Software Support for the Agentry Server

The Agentry Server fully supports deployment on virtual machine host systems. When sizing a virtual host system, there is no difference in virtual hardware requirements and physical hardware requirements. A given virtual machine should be configured with the same memory and storage needs. As with the requirements of a physical host, a virtual host must be dedicated for the Agentry Server and should not be the same host as may be in use for the back end system. The following tables provide the lists of virtualization software solutions supported by the Agentry Server. The first table lists the supported solutions for creating virtual machines. The second table lists the supported solutions for hosting and running the virtual machines. Table 1: Supported VM System Creation and Configuration Software
Software VMware VM Workstation VMware vCenter Converter
NOTE:
Supported Versions 5.0, 5.5, 6.0, 6.5 All versions
In addition to the above, the VM host may be configured using the VMware ESX tools available, with the supported versions for this software listed below. Table 2: Supported VM Host and Execution Software
Software VMware ESX VMware ESXi VMware VMPlayer 3.5, 4.0 3.5, 4.0 1.0 through 2.5 Supported Versions
21
Agentry Server Hardware Requirements 32-bit Windows Server

The Agentry Server can be installed on a 32-bit Windows Server. However, the 32-bit Windows Server operating system has a default limit of 2 gigabytes of memory for a single process. Because of this limitation, Syclo recommends that the number of Client users for an Agentry Server installed to the 32-bit builds of Windows Server be kept to 100 or less. If you plan on scaling and growing your mobile application deployment, Syclo recommends implementing either the 64-bit Windows Server or the Linux Server solutions. When planning any Agentry Server implementation, be sure to involve a Syclo Architecture Consultant to review and approve the final configuration.
Minimum Hardware Requirements

The requirements listed in the following table are estimated. Each individual installation will need to be sized for peak load requirements, transferring of large external files, the amount of data being retrieved, and frequency of synchronization.
Users 100 or less 1
Dual Core Processors 4
RAM (GB)
Hard Drive Size (GB) 50
Assumptions
The hardware requirements are made with the following assumptions: Log files are kept for a maximum of 30 days. A processor is defined as a dual core processor with a minimum speed of 2 GHz.
22
Agentry Server Hardware Requirements 64-bit Windows Server

The Agentry Server can be installed on a 64-Bit Windows Server, which offers greater scalability and growth for Agentry Server users. When planning any Agentry Server implementation, be sure to involve a Syclo Architecture Consultant to review and approve the final configuration. For larger implementations requiring fault tolerance and high up time, a hardware load balancer should be used to direct network traffic to multiple Agentry Server instances. Refer to Syclos Clustered Network Environment Technical Bulletin .

The hardware requirements listed in the following table are estimated. Each individual installation will need to be sized for peak load requirements based on application size, push requirements, transferring of large external files, amount of data being retrieved, and frequency of synchronization.
Users 250 and less 500 1,000 2,500 5,000 10,000 1 2 4 6
Dual Core Processors 4 8 16 32 64
RAM (GB) 50 50 50 100 100 100
Hard Drive Size (GB)
12 24
128
Assumptions
The hardware requirements are made with the following assumptions: The number of users is spread across all Agentry Servers. Log files are only kept for 30 days. A processor is defined as a dual core processor with a minimum clock speed of 2 GHz.
23
Agentry Server Hardware Requirements 64-bit Linux Server

The Agentry Server can be installed on a 64-bit Linux Server. The Agentry Server is compatible with the following versions of Linux:
NOTE:
CentOS 5.2 Red Hat Enterprise 5.2 Linux SuSE Enterprise Linux 10 Solaris 10 Operating System Linux kernel version 2.6.17 or later. 64-bit builds only.
When planning any Agentry Server implementation, be sure to involve a Syclo Architecture Consultant to review and approve the final configuration. For larger implementations requiring fault tolerance and high up time, a hardware load balancer should be used to direct network traffic to multiple Agentry Server instances.

The hardware requirements listed in the following table are estimated. Each individual installation will need to be sized for peak load requirements based on application size, push requirements, transferring of large external files, amount of data being retrieved, and frequency of synchronization.
Users 250 and less 500 1,000 2,500 5,000 10,000 1 2 4 6
Dual Core Processors 4 8 16 32 64
RAM (GB) 50 50 50 100 100 100
Hard Drive Size (GB)
12 24
128
Assumptions
The hardware requirements are made with the following assumptions: The number of users is spread across all Agentry Servers. Log files are kept for a maximum of 30 days. A processor is defined as a dual core processor with a minimum clock speed of 2 GHz.
24
CentOS and Red Hat Linux System Requirements

The following table lists the system and software requirements for the Agentry Server. Verify these requirements are met prior to installing the Server software to the host system.
Software CentOS 5.2 -- or -- Red Hat Enterprise 5.2 OpenSSL libicu libxml2 libxslt
Version Linux kernel version 2.6.17 or later. 64-bit builds only. 0.9.8x, NOTE: do not use 0.9.9 or later 3.4 or later 2.6.23 or later 1.1.17 or later
25
Agentry Editor Hardware Requirements

For all releases of the Agentry Mobile Platform version 5.0 or later, the Agentry Editor is provided as a plug-in for the Eclipse Platform. This platform is designed and built to support numerous third-party plug-ins and tools. Each of these tools will have their own system requirements and supported operating systems that may impact the proper configuration for a specific environment. The following system requirements are based on the configuration of the Eclipse Platform provided with the Agentry Editor installer. If you have an existing Eclipse implementation to which the Agentry Editor plug-in is being added, the system requirements of your tools should be factored into any considerations about the physical host system. Processor : Intel Pentium IV class processor with minimum clock speed of 2.4 GHz Memory : 1GB of available system RAM (2 GB recommended) Storage : Approximately 200 MB of available storage space for all components provided by the installer. NOTE: This excludes storage space need for development projects or other related files. Network : A network connection using TCP/IP for publishing applications from the Editor to Agentry Servers running on separate hosts.
26
Agentry Editor Software Requirements

The following requirements for the Agentry Editor pertain to the host system to which the Editor is to be installed. These requirements assume the Editor is not being installed to the same host system as the Agentry Server. In the event the Editor and Server are installed to the host system, adhere to the system requirements of the Server. With the release of the Agentry Mobile Platform version 5.0, the Editor is provided as a plug-in to the Eclipse Platform. This platform supports a wide array of operating systems. However, the Agentry Editor plug-in currently supports only Windows operating systems as listed below. Operating Systems: Windows XP Professional Windows Server 2003, 2008
Java Development Kit/Java Runtime Environment version 1.6 (a.k.a Java 6) or later. Note that this version of the JDK and JRE are required by Eclipse. Additional JDK/JRE versions may be installed for the purposes of development work, should the back end system require them. The minimum supported JDK version by the Agentry Java API is 1.5. If developing for a database, the JDBC Drivers for connections to the database system through the Eclipse Data Source Tools. The proper drivers needed will depend on the type of database in use. This connection is needed for the Connector Studio functionality provided with the Agentry Editor for database back end systems. This functionality is optional for database development, but is a powerful aid to this work. For Java systems, this is not necessary.
27
Agentry Client Requirements

The requirements for the Agentry Clients vary from one client executable to the next. The following hardware and software requirements are, therefore, organized according to the general supported device types. Storage and/or memory requirements are based on common application configurations. For implementations in which larger than normal amounts of data are stored on the Client, additional storage may be necessary. A Syclo systems architect should consulted regarding the needed resources for a client device in relation to the intended application deployment.
Agentry MDM Note

The Agentry MDM solution includes a separate, additional client component, plus cabinet files and other resources that will be stored on the client device. These items must be stored on the devices non-volatile flash storage. This area of storage can be limited in size for certain client device types. Alternately, a flash card can be added to these devices for the purposes of storing Agentry MDM-related resources. This is a recommended practice and is above an beyond the storage and resource items noted here. See the system requirements for the Agentry MDM solution for details on the client device flash storage needs.
Windows CE 3.0, 2000, 2003, CE.net, and Windows Mobile 5 and 6

Devices running the Windows CE 3.0, CE .net, 2000, 2003, Windows Mobile 5or later operating systems are supported. These devices can be running either the Pocket PC or Handheld PC shell. Such devices should have a minimum of 64 MB of memory.
Desktops, Laptops, and Tablets

The Agentry Client can be run on Desktop and Laptop PCs, as well as tablets, provided they are running Windows XP Professional.The minimum processor should be a Pentium IV at 2.0 GHz clock speed with 1 GB of RAM (2 GB recommended) and 100 MB of available storage.
28
SMART Mobile Suite Administration Requirements

The following lists incldue the minimum prerequisite software versions and support packages for the SMART Mobile Suite Administration Component. It should be verified that these minimum software versions are met prior to installing the Administration Component to SAP ERP. Note that later versions of these components are fully supported, and that these items represent only the minimum versions. Table 3: Minimum Software Component Releases and Support Packages
Software Component SAP_ABA SAP_AAPL SAP_HR SAP_BASIS 700 600 600 700 Release Support Package Support Package 09 Support Package 06 Support Package 07 Support Package 09
SMART Mobile Suite Administration Component Installation
30
SMART Mobile Suite Administration Component Installation Overview

The SMART Mobile Suite Administration Component is installed to the SAP system as a part of the implementation of the SMART Mobile Suite for SAP Systems mobile solution. The Administration Component includes both the Administration and Monitoring Portal, and the Integration Framework. The Integration Framework provides the integration point to SAP for the SMART Server. This then allows the SMART Server to synchronize data with the SAP system for the mobile application. Included in the Integration Framework is the Configuration Portal used during implementation to modify and extend the standard functionality of the synchronization components to meet implementation-specific needs. The Administration and Monitoring Portal provides the tools and user interface to allow for the administration, configuration, and care and feeding tasks for the integration framework. These include security settings, log settings, and other similar tools. The installation of the Administration Component includes the following main tasks: 1) Verifying the system requirements. 2) Installation preparation, including downloading the software and support packages to install the Administration Component. 3) Installation of the SMART Mobile Suite Administration Component software and support packages. 4) Activation of the Administration Component in the target client for the SAP system. 5) Definition and scheduling of background jobs that maintain the synchronization components within the Integration Framework. Each of these procedures are detailed in the following sections. Once the installation of the SMART Mobile Suite Administration Component, as well as the other software components within the SMART Mobile Suite for SAP Systems mobile solution is complete, the standard functionality as provided by Syclo is available. The next phase in the implementation will be the modification and extension of the SMART application for implementation-specific requirements. This can include changes to the application project using the Agentry Editor, as well as changes made in the Administration Component about to be installed.
31
Installing SMART Mobile Suite Administration Component for SAP ERP

Prerequisite Current versions of kernel, TP and R3trans Current SPAM / SAINT Update - Compare the short text of the last SPAM / SAINT Update you imported with that of the SPAM / SAINT Update in the SAP Service Marketplace. If the version of the SPAM / SAINT Update in the SAP Service Marketplace is more recent, import it. Verify the required software components have been installed, as listed in the system requirements for the SMART Mobile Suite Administration Component for SAP ERP. Verify the required support packages have been installed, as listed in the system requirements for the SMART Mobile Suite Administration Component for SAP ERP. No SAP password is required.
Additional Information Space required in the transport directory: approximately 10 MB Total runtime: approximately 0.5 hours Add-On Media for SAP ERP with Enhancement Pack 4: ERP 320_700 Add-on Installation Package: S4SAPERP_320700_NW701.SAR ERP 320_700 Add-on SP1: S4SAPERP_320700_SP1_NW701.SAR ERP 320_700 Add-on SP2: S4SAPERP_320700_SP2_NW701.SAR ERP 320_700 Add-on SP3: S4SAPERP_320700_SP3_NW701.SAR ERP 320_700 Add-on SP4: S4SAPERP_320700_SP4_NW701.SAR ERP 320_700 Add-on SP5: S4SAPERP_320700_SP5_NW701.SAR ERP 320_700 Add-on SP6: S4SAPERP_320700_SP6_NW701.SAR ERP 320_700 Add-on Installation Package: S4SAPERP_320700_NW700.SAR ERP 320_700 Add-on SP1: S4SAPERP_320700_SP1_NW700.SAR ERP 320_700 Add-on SP2: S4SAPERP_320700_SP2_NW700.SAR ERP 320_700 Add-on SP3: S4SAPERP_320700_SP3_NW700.SAR ERP 320_700 Add-on SP4: S4SAPERP_320700_SP4_NW700.SAR ERP 320_700 Add-on SP5: S4SAPERP_320700_SP5_NW700.SAR ERP 320_700 Add-on SP6: S4SAPERP_320700_SP6_NW700.SAR
Add-On Media for SAP ERP with Enhancement Pack 3:
32

Language Support The SMART Mobile Suite Administration Component supports the following languages: English
Procedure OverviewOverview The following tasks comprise the installation procedure for the SMART Mobile Suite Administration Component for SAP ERP. When this procedure has been completed the administration component will be installed to the SAP ERP system and activated. This procedure also includes the following post-installation changes and/or additions: Activation of the BC Set in the Syclo target client. Activation of the service for the Web Dynpro ABAP Application Definition of the background jobs for system operation, including exchange data processing and optional push processing.
Procedure
33
Preparation for Installation

1. Log on to your SAP system as client 000 and as a user that has system administrative privileges. Do not use the SAP* or DDIC users. 2. Import the required user language(s) for all components that have already been installed. This language import must be performed prior to the installation of the SMART Mobile Suite Administration Component
34
Software Installation
1. Load the software package into your system via the Add-On Manager, using the transaction code SAINT. Note: For more information about this, see the online documentation for the Add-On Installation Tool. Choose the help function in the application toolbar and navigate to Online Documentation | Loading Installation Packages . 2. Start the installation of the SMART Mobile Suite Administration Component for SAP using the Add-On Installation Tool, accessed from the transaction SAINT. Note: For more information about this, see the online documentation for the Add-On Installation Tool, selecting the help function on the toolbar. 3. Load the support packages into your system via the Support Package Manager, using the transaction code SPAM. 4. Install the support packages for the SMART Mobile Suite Administration Component for SAP, accessed from the transaction SPAM.
35
Post Installation - Required

Procedure Overview As a part of the post installation procedure, there are both required and optional tasks. This procedure covers the required tasks, which include activating both the BC Set and the service for the Web Dynpro ABAP application, the definition of intervals for certain number objects, and the configuration of the exchange table purge background job. Procedure 1. Activate the /SYCLO/SMART_SERVICE_MANGER_20_CUS BC Set a. Log on to the target client for the SAP application as a user with administrative privileges. b. Start the transaction SCPR20. c. Activate the BC Set /SYCLO/SMART_SERVICE_MANGER_20_CUS. 2. Activate the Services for the Web Dynpro ABAP Applications a. Start transaction SICF. b. Activate all services under the node default_host/sap/bc/webdynpro/Syclo 3. Define Intervals for Number Range Objects /SYCLO/C_1 and /SYCLO/C_2 . a. b. c. d. e. Start transaction SNRO. Enter the number range object /SYCLO/C_1. Select Number Ranges | Intervals . Maintain or create the intervals 01 and 02 Repeat these steps for the number range object /SYCLO/C_2.
4. Define Background Job: Exchange Table Purge a. Define a variant for the program /SYCLO/CORE_EXCH_PURGE_PROG with the Mobile Application attribute set to SMART_SERVICE_MANAGER_20. b. Define a periodic background job for the /SYCLO/CORE_EXCH_PURGE_PROG program with transaction code SM36, using the variant defined in the previous step. Set the frequency so that this process is run daily.
36
Post Installation - Optional

Procedure Overview The following post installation tasks cover the definition of background jobs and are optional based on the desired functionality for the implementation. Following is a list of these optional tasks and the situations in which they may be defined: Define Background Job: Push Scenario: This background job should only be defined when the SMART implementation includes server push functionality. Implementation of this behavior includes this background job, as well as other possible changes to the standard SMART application. Define Background Job: Push Registry Purge: This background job should only be defined when the server push functionality is implemented. This job periodically removes data stored in relation to push synchronization. This data is needed only for a finite time period and can be safely removed once all business objects are pushed to clients by the SMART Server. This purge job should always be defined when the push scenario background job is defined. Define Background Job: System Statistic Calculation: This background job should only be defined if the system statistics are enabled in the Administration and Monitoring Portal for the SMART Mobile Suite. This job performs statistic calculations on the data generated by the system statics feature. Define Background Job: System Statistic Records Purge: This background job should only be defined if the system statistics are enabled in the Administration and Monitoring Portal for the SMART Mobile Suite. This job purges unneeded records generated by the system statistic calculation job.
The details on defining each of these jobs is provided next. It is not necessary to define all of the jobs, and those not applicable to the implementation can be skipped. Procedure 1. Define Background Job: Push Scenario a. Define a variant for program /SYCLO/CORE_PUSH_PROC_PROG with the Mobile Application attribute set to SMART_SERVICE_MANAGER_20. b. Define a job for /SYCLO/CORE_PUSH_PROC_PROG as either a periodic job or a trigger by event job with transaction SM36, using the variant from the previous step. For a periodic job set the frequency according to the requirements of the push processing. This interval will define the frequency for object pushes to the client applications. For a trigger by event job, the event is /SYCLO/BACKGROUND_JOB_EVENT with a parameter value of EXCHOBJ_PUSH_EVENT. If this event does not exist in the system, define a custom event of /SYCLO/BACKGROUND_JOB_EVENT using transaction code SM64. 2. Define Background Job: Push Registry Purge a. Define a variant for program /SYCLO/CORE_PUSH_PURGE_PROG with the Mobile Application attribute set to SMART_SERVICE_MANAGER_20. b. Define a periodic background job for program /SYCLO/CORE_PUSH_PURGE_PROG with transaction SM36, using the variant created in the previous step. Set the frequency so that this process is run daily.

3. Define Background Job: System Statistic Calculation
37
a. Define a variant for program /SYCLO/CORE_SYSSTATS_UPD_PROG with the Mobile Application attribute set to SMART_SERVICE_MANAGER_20. b. Define a periodic background job for program /SYCLO/CORE_SYSSTATS_UPD_PROG with transaction code SM36, using the variant defined in the previous step. Set the frequency so that this job is run once per hour. 4. Define Background Job: System Statistic Records Purge a. Define a variant for program /SYCLO/CORE_SYSSTAT_PURGE_PROG with the Mobile Application attribute set to SMART_SERVICE_MANAGER_20. b. Define a periodic background job for program /SYCLO/CORE_SYSSTAT_PURGE_PROG with transaction code SM36, using the variant from the previous step. Set the frequency so that this process is run daily.
Work Manager Server Installation
39
Install the Java SDK and JRE Software

Procedure Overview The SMART Server uses Java to perform data synchronization between itself and the SSAP system. The Java Development Kit (JDK) version 1.6 or higher is required for the SMART Server.
NOTE:
Installation to Windows systems requires the proper build of the JDK be installed based on the build of the Windows system. The 32-bit build of the JDK should only be installed for 32-bit builds of Windows. The 64-bit build should only be installed for 64-bit builds of Windows.
Included in the JDK installation is the Java Runtime Environment, or JRE. This procedure should be performed before the installation of the SMART Server. The installation location of the JDK should be noted, as it will be needed during configuration of the SMART Server after it has been installed. Procedure 1. Download the installer for the JDK 1.6 or later from the following address: http://java.sun.com/ 2. Download the correct JDK for your system. Install the 64-bit JDK for 64 bit Linux and Windows operating systems and the 32-bit JDK for 32-bit Windows systems. 3. Run the JDK installer and the Java JRE installer. Syclo recommends that you accept all default values. If you install these components to a different location, be sure to note these locations. 4. For Windows implementations only: Modify the Windows environment variable Path once the JDK and JRE have been installed. Two new paths for the JDK need to be added. One is for the bin directory of the JDK and the other is the bin directory for the Java Runtime Environment (JRE). Add the following two paths, separated by a semi-colon. Substitute the proper path information based on the location of the installation and the Java version: C:\Java\jdk1.6.0_06\bin;C:\Java\jdk1.6.0_06\jre\bin\server
40
Installing the SMART Server For Windows

Prerequisite Prior to installing the SMART Server the following items must be addressed: The host system must meet the system requirements as provided with the application. The Java SDK and JRE must be installed to the host system. The SMART Mobile Suite Administration Component must be installed to the SAP system. The name, client number, and system number of the SAP Application Server to which the SMART Server will connect.
Procedure Overview This procedure describes the steps to install the SMART Server software to a Windows system. This procedure is the same for Windows Server and Windows XP Professional systems. Note that the 64-bit build of the SMART Server can only be installed to 64-bit operating systems. The 32-bit build of the SMART Server can be installed to either 32- or 64-bit Windows systems, but will not take advantage of the 64-bit memory addressing. The SMART Server should never be installed to a Windows XP Professional host system for production purposes. This operating system is supported by the installer solely for development purposes. Production servers should always be installed to server class host systems. When this procedure is complete, it will be necessary to perform initial configuration of the SMART Server. Specifically, configuration options related to communications between the SMART Clients and the SMART Server, and related to communications between the SMART Server and the SAP system must be set according to the specifics of the implementation environment. For production environments in which multiple SMART Server instances will be installed for load balancing and fail-over, this procedure should be performed for each SMART Server instance. Additionally, information provided on establishing SMART Server Clusters using the Agentry Administration Client should be reviewed. Procedure 1. Launch the installer executable for the SMART Server.

The Welcome screen will display.
41
2. Click the Next button to continue the installation. This will display the License Agreement screen:
3. Click the Yes button to agree to the license agreement and to begin installing the SMART Server. The Customer Information window will display.
42

4. Enter the name of the administrator for the Agentry Server and the company name. In the Serial Number field, enter the number provided with the SMART Server Installer. Click Next to continue. The Enter Product Keys window will display.
5. Enter the user key, device key, and expiration keys provided by Syclo. Click Next to continue. The Setup Type window will display.
43
6. Select the type of SMART Server you want to install. Select Production for live, production environments. Select Development for development or test environments. If both are selected, two separate SMART Servers will be installed in separate locations. Click Next to continue. The SAP Connectivity Information window will display.
7. Enter the name of the SAP Server and its port number in the Server field, using the format: servername:portnumber. If both a Production and Development Server are being installed, this previous screen will be displayed twice, once for each Server instance. Enter the appropriate information for both SMART Server instances. 8. Enter the Client number and System Number the SMART Server will use to communicate with the SAP Application server. Click Next to Continue. The Java Backend Information window will display.
44

9. The default values for the Java Backend class paths should only be changed if you wish to point the sever to a different SAPjco.jar file or a different runtime environment. 10. Click Next to continue. The Choose Destination Location window will display.
11. Specify a folder to install the SMART Server in. To change the default folder, click Browse and navigate to the desired folder. Note: If Both Production and Development Server installations were selected in the Select Type window, These windows will display once for the Production server and once for the Development server. Click Next to continue. The Shortcuts for the Production Server window display.
45
12. In addition tot he shortcuts for the Server instance, the option to install the Server as a Windows Service is also provided. Check this box to install the Server as a Service if this is the desired configuration. Note that this is commonly set for Production Servers but rarely for Development Servers. Also, select what shortcuts and where they should be located from the Shortcuts window. Note: If Both Production and Development Server installations were selected in the Select Type window, These windows will display once for the Production server and once for the Development server.
46

13. Click Next To Continue. The Installing Window will display and indicate installation Status.
14. When the installation is complete, you may be prompted to reboot the host system. Select the desired option and click the [Finish] button to complete the wizard.
Result The SMART Server software has been installed to the Windows host system. This includes the server executable, as well as the SMART application, as provided by Syclo. After Completing This Task The SMART Server instance now requires initial configuration based on the implementation environment. This configuration includes: Client-server communications settings. Server-SAP system communications settings. Security and authentication settings. For multiple Server instances, clustering settings and behaviors.
The specifics of the Server-SAP system communications settings depends in large part on the
47
configuration of the SAP system. Specifically, whether the SAP system is configured in a distributed environment, or if it is in a load balanced environment. Follow the procedures provided for the implementation-specific needs.
48
Installing the SMART Server on CentOS 5.2 Linux

Prerequisite The following items should be addressed prior to installing the SMART Server: The system requirements for the SMART Server should be verified and met on the host Linux system. Root access to the Linux host system must be available. You should have the compressed tar file named S4SAPSM_1000_Server_Linux_CentOS5.2-x86.tar.gz and the associated software license keys.
Procedure Overview The following procedure contains the steps to install and configure the SMART Server on the CentOS 5.2 64-bit Linux operating system. The person performing this procedure should log into the system as the root user. Procedure 1. Create the directory: /opt/syclo/SMART-SM-Server 2. Copy the compressed tar file S4SAPSM_1000_Server_Linux_CentOS5.2-x86.tar.gz to this new directory. 3. Run the following command: tar -xzvf S4SAPSM_1000_Server_Linux_CentOS5.2-x86.tar.gz The Server files will be extracted to the current directory, including several sub-directories. 4. Change to the directory bin/ created by the extraction and run the following command: chmod +x * 5. The Servers license keys must now be entered. Remain in the bin directory and run the command: agentry-setup.sh This will display the software license agreement and a series of prompts to enter the various software keys for the SMART Server. Follow these instructions, entering the information requested.
49
6. Change to the directory ../conf. Here, edit the file javaBE.ini using a text editor such as vi. Make the following changes to this file: a. Within the section [Host], set the configuration option server= to the name of the SAP Application Server. b. Within the section [CLIENT_NUM] change the setting CLIENT= to the client number for the SAP Application Server. c. Within the section [SYSTEM_NUM] change the setting SYSNUM= to the System Number for the SAP Application Server. d. Save the modifications and close the file. 7. Change directories back to the ../bin directory. From here the SMART Server can be started. The following is the command syntax to run the Server and includes optional parameters: start-agentry.sh [-d] [-user user name] -d: Run as a daemon and disconnect from the terminal -user user name: The user name to run under when the process starts. Privileges will be dropped from root to this user during process startup. It will regain root privileges only if it needs to perform OS-Level user authentication via a File System Connection. The above command may also be used in the init.d file. It is recommended that the SMART Server be run under a user other than root by specifying the -user option. This user must have read-write privileges for the directory into which the SMART Server has been installed and all sub-directories.
50

8. To provide access to the SMART Server from either the Agentry Editor or the Administration Clients, it is necessary that Samba be installed and configured on the host Linux system. Once the SMART Server has been installed, the directory /opt/syclo/SMART-SM-Server/conf must be added as a SAMBA file share. For information on installing and configuring Samba, see the official Samba website at: http://www.samba.org Note that Samba is not necessary if working in a production environment where only SMART Clients will be connecting to the Server. Result The SMART Server software has been installed to the Windows host system. This includes the server executable, as well as the SMART application, as provided by Syclo. After Completing This Task The SMART Server instance now requires initial configuration based on the implementation environment. This configuration includes: Client-server communications settings. Server-SAP system communications settings. Security and authentication settings. For multiple Server instances, clustering settings and behaviors.
The specifics of the Server-SAP system communications settings depends in large part on the configuration of the SAP system. Specifically, whether the SAP system is configured in a distributed environment, or if it is in a load balanced environment. Follow the procedures provided for the implementation-specific needs.
51
Configuring the SMART Server to the SAP Systems Time Zone

Procedure Overview Set the SMART Server Time zone to the same time zone as the SAP system. Procedure 1. Open the Agentry.ini file found in the directory the SMART Server was installed in. 2. Navigate to the [Java-1] section of the file and set the following attribute to the time zone that the SAP system is set to:timeZoneName=SAPs Time Zone Name Example: SAP Server Time Zone (GMT-05:00) Eastern Time (US & Canada) Set timeZoneName As: timeZoneName=(GMT-05:00) Eastern Time (US & Canada) Note: The time zone name value must match the time zone value on the OS of the SAP server exactly. The time zone setting can be found in the SAP severs registry setting: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones Note: The Current time zone equivalent time zone name can also be used. For example, Eastern Standard Time can be used instead of Eastern Time Zone.
52
Connecting SMART Server to a Distributed SAP Environment

Procedure Overview If the SMART Server is going to connect to a database that is deployed in a distributed environment, follow the procedure in this section. Proceed to the next section if this is not the case. The JavaBE.ini file is located in the directory where the SMART Server was installed. This file is used to configure additional settings on the Server. Procedure 1. Open the JavaBe.ini configuration file in a standard text editor. 2. Search for the section [LOGON_METHOD]:
[LOGON_METHOD] ; USER_AUTH if standard UID/Password authentication is used ; USER_AUTH_GLOBAL if pooled connections using single UID/Password is used ; USER_AUTH_GROUP if UID/Password authentication with SAP Message Server ; (load balancing) is used LOGON_METHOD=USER_AUTH
3. Set the LOGON_METHOD property to USER_AUTH. 4. Save and close the JavaBe.ini file.
53
Connecting the SMART Server to a Load Balanced SAP System

Procedure Overview If the SMART Server is going to connect to a database that is deployed in an environment with load balancing, follow the procedure in this section. Proceed to the next section if this is not the case. The JavaBE.ini file is located in the directory where the SMART Server was installed. To configure the server for a distributed environment: Procedure 1. Open the JavaBe.ini configuration file in a standard text editor. 2. Search for the section [LOGON_METHOD]:
[LOGON_METHOD] ; USER_AUTH if standard UID/Password authentication is used ; USER_AUTH_GLOBAL if pooled connections using single UID/Password is used ; USER_AUTH_GROUP if UID/Password authentication with SAP Message Server ; (load balancing) is used LOGON_METHOD=USER_AUTH
3. Set the LOGON_METHOD property to USER_AUTH_GROUP. 4. Search for [GROUP_LOGON]:

[GROUP_LOGON] ; referenced when LOGON_METHOD=USER_AUTH_GROUP ; individual user authentication using an SAP Message Server which distributes ; client connections among a "group" of SAP application servers based on load ; balancing criteria ; ; host name or IP address of SAP Message Server MESSAGE_SERVER= GROUP_NAME= SYSTEM_ID= CLIENT=
5. Set the properties for the [GROUP_LOGON] to the following parameters: a. b. c. d. Set the MESSAGE_SERVER to host name or IP address of the SAP Message server. Set the GROUP_NAME to the name of the group of application servers. Set SYSTEM_ID to the name of the SAP system or the SAP Name. Set CLIENT to client number the SMART Server will use to communicate with SAP.
6. Save and close the JavaBe.ini file.
54
Testing Connectivity to SAP Systems

Prerequisite Prior to performing this connection test, the following items must be addressed: The SMART Server must be installed and the configuration files agentry.ini and JavaBE.ini must contain the settings as described in the server installation procedeure. The person performing this procedure should log into the host system with administrative privileges. This procedure is only applicable to Windows installations of the SMART Server.
Procedure Overview Use the following procedure to confirm the SMART Server is able to communicate with the SAP system. To confirm the SMART Server can communicate with the SAP application: Procedure 1. Edit the file connectTest.bat, located in the SMART Server directory in a text editor. Edit the class path to reflect the location of the sapjco.jar file. 2. Open a Command prompt window and change to the SMART Servers directory. Run the following script to test if the server can communicate with the SAP system: connectTest.bat If the communications between the SMART Server and the SAP system are configured correctly, the script will out put the following:

If the Script fails, it will output:
55
Verify the Servers settings are all correct before continuing. 3. After the connectTest.bat script succeeds in connecting with the SAP system, start the SMART Server by clicking the server icon, or following the start service instructions. 4. Verify that no error messages are displayed, either popup messages, or log messages displayed on the Server's user interface. If no errors are encountered, the SMART Server was able to open communications with the SAP system. If you encountered any errors, review this procedure and verify you followed each step correctly. Pay particular attention to the configuration settings you modified in the configuration files for the SMART Server.
56
Additional JavaBe.ini Settings

The following table describes additional settings in the JavaBe.ini configuration file. Note that these complex tables should remain enabled except for testing or debugging purposes.
Setting [TABLE_REFRESH]
Description These are used to determine when to refresh the complex and data tables. Values in hours -1 = never 0 = every time 1 week = 168 1 month = 720
Default CTEquipment=720 CTFunctionalLocations=720 CTParts=720 CTMaterialStorageLocation=720 CTPartUOM=720 CTWorkCenters=720 CTActivityType=168 CTAttendanceType=168 CTCodeGroup=168 CTControlKey=168 CTNotificationType=168 CTPersonResp=168 CTPlanSite=168 CTPriority=168 CTRemedy=168 CTStorageLocation=168 CTVarianceReason=168 CTCatalogProfile=168 CTTimeIncrements=168 DTAccountIndicator=0 DTBusinessAreas=0 DTHoldReason=0 DTItemCat=0 DTProcessingStatus=0
57
Description Default CTEquipment=0 CTFunctionalLocations=0 CTParts=0 CTMaterialStorageLocation=0 CTPartUOM=0 CTWorkCenters=0 CTActivityType=168 CTAttendanceType=168 CTCodeGroup=168 CTControlKey=168 CTNotificationType=168 CTPersonResp=168 CTPlanSite=168 CTPriority=168 CTRemedy=168 CTStorageLocation=168 CTVarianceReason=168 CTCatalogProfile=168 CTTimeIncrements=168 DTAccountIndicator=0 DTBusinessAreas=0 DTHoldReason=0 DTItemCat=0 DTProcessingStatus=0 CTActivityType=1 CTAttendanceType=1 CTCodeGroup=1 CTControlKey=1 CTNotificationType=1 CTEquipment=1 CTFunctionalLocations=1 CTMaterialStorageLocation=1 CTParts=1 CTPartUOM=1 CTPersonResp=1 CTPlanSite=1 CTPriority=1 CTRemedy=1 CTStorageLocation=1 CTTimeIncrements=1 CTVarianceReason=1 CTWorkCenters=1 CTCatalogProfile=1 DTAccountIndicator=1 DTBusinessAreas=1 DTHoldReason=1 DTItemCat=1 DTProcessingStatus=1
Setting [TABLE_CHECK]
These are used to determine when to check the complex and data tables Values in hours -1 = never 0 = every time 1 week = 168 1 month = 720
[ENABLE_TABLE]
These are used to skip some large complex and data tables for testing. Enter: 1 =Get the table 0= Ignore the table
58
Setting [LANGUAGE] [LOGGING]
Description This sets the default language This sets the Logging Level 1=Fatal 2=Error 3=Warning 4=Info 5=debugy 6=trace LANG=EN Level=4
Default
59
Configuring Agentry Client-Server Communications

Prerequisite Configuration of the ANGEL secure communications requires the following items to addressed prior to modifying the configuration files for the Agentry Server: Address SSL authentication items, including whether or not a different authentication certificate will be needed for the Server. By default a certificate is provided named AgentryServer.pfx. Determine if the Client will be required to be authenticated via SSL. If so, trusted root certificates are needed on the Server with matching entries for the authentication certificates installed on the Clients. Determine if the default time out of 300 seconds and keep-alive duration of 60 seconds are adequate. If not, determine the proper values for these items as they will be configured in this procedure. Retrieve and record the proper domain/IP address(es) and port number(s) upon which the Agentry Server will receive requests from Clients.
Procedure Overview This procedure describes the steps necessary to configure the client-server communications for the mobile application. Configuration of the ANGEL communications section is required for any deployment of an application. Many of the necessary settings for this connection type are implementation-specific. This process involves the modification of the [ANGEL Front End] and [ANGEL Front End Ports] sections of the Agentry.ini file. Changes to these sections should always be made using the AgentryAgentry Administration Client. Procedure 1. Start the Agentry Agentry Administration Client and connect to the Agentry Server instance If the Server is not running, start the Server and connect the Administration Client to it. 2. Within the Agentry Administration Client, select the menu item Edit | Configuration Settings . Alternatively, right-click on the Server instance to configure in the Agentry Administration Client and select the menu item Edit Configuration Settings . This will display the Edit Configuration Settings screen. Here, select the tab ANGEL Front
60

End .
3. Edit the settings on this screen to allow the Agentry Server to support the client-server communications for the implementation environment. Following are the settings that may be configured for these options: trustedCertificateStore: Specifies the trusted certificate store containing the trusted certificate(s) used when client authentication is enabled (authenticateClient=true). This may be specified as a Certificate File (.CER) or Certificate Store File (.SST). authenticationCertificateStore: This setting specifies the location of the Servers authentication certificate. This may be a Certificate File (.CET), Certificate Store File (.SST), or a Personal Information Exchange File (.PFX). The certificate identified here must be a trusted root certificate for the Agentry Clients. authenticationCertificateStorePassword, authenticationCertificateStorePasswordEncoded: The password to access the authentication certificate identified in authenticationCertificateStore. Password encoded indicates whether or not the password listed here is encoded. This password may only be encoded if authenticationCertificateStore is set to a value other than the default AgentryServer.pfx. authenticateClient: Specifies whether or not the Agentry Client must provide an authentication certificate. This certificate must be traceable to a trusted root certificate, though intermediary authorities may exist. timeout: This is the duration of time in seconds the Agentry Server will keep a socket open between the Server and the Agentry Client without any activity. Once this limit is reached, the socket will be closed. keepAliveTime: This is the duration of time between keep alive messages being sent from the Server to the Client, preventing the time out value from closing the
61
socket. This keepAliveTime is used only when background sending or push functionality is enabled for the application. minimum-, maximumCipherStrength: These two settings specify, in bits, the cipher strength of the data encryption used by this connection type. Leaving these items commented out (as above) or omitting them results in Windows determining the cipher strength.
4. Close the Configuration screen by clicking the [OK] button. This will save the changes made and restart the Agentry Server where necessary. 5. Next, open the Agentry.ini file for the Agentry Server. Here, search for the section [ANGEL Front End Ports]. This section must be edited manually initially. Adding new port options to this file cannot be done through the Agentry Administration Client, though the settings can be modified using the Agentry Administration Client once added to the file. The Server can be configured to listen on one or more ports and network adapters. Note that if multiple Agentry Servers are deployed for the same application, these items will need to be configured separately for each Server instance. These settings cannot be configured using the Agentry Administration Client for Agentry Servers within a cluster unless all Servers have the same port settings. This is typically not the case. [ANGEL Front End Ports] port1=7003 port2=127.0.0.1:7013 port3=localhost:7080 port4=MyHostSystem:7020 As is normally the case, these ports must be free. They may also be specified via port name. Whatever port is listed first in this section is used as the default port. All entries must include a port number and may include the host name or IP address. Finally, any IP addresses or host names listed here must have corresponding network adapters configured on the host system. 6. Review the modifications just made to this file. When satisfied of their accuracy, save and close the Agentry.ini file. 7. Restart the Agentry Server in order for these modifications to take affect. Result When this is complete, the communications between the Agentry Clients and Agentry Server will be configured. After Completing This Task When the communications settings have been changed, the communications between the Client and Server should be thoroughly tested. If multiple communications methods are employed, i.e. if there are multiple ports configured in the [ANGEL Front End Ports] section, connections should be made from Agentry Clients using each of these possible network addresses and/or port numbers.
Installing the Agentry Editor
63
Installing the Agentry Editor Plug-In and Eclipse Platform

Prerequisite Before installing the Agentry Editor: If a current Eclipse implementation exists, determine the version. The version installed with the Agentry Editor plug-in is Ganymede (Eclipse v3.4). The Editor plug-in is not compatible with previous versions. If a prior version of Eclipse is installed a decision must be made regarding whether or not to upgrade the existing Eclipse Platform, or to install the Ganymede version with the Editor plug-in to a separate location. If an existing Eclipse Platform is to be upgraded, see the overview information provided below. If any other Agentry components (Server, Clients) have been installed to the same host system, those components must not be running during installation. Verify they have been shut down, including any Agentry Server instances running as Windows Services.
Procedure Overview Beginning with the release of the Agentry Mobile Platform version 5.0, the Agentry Editor is provided as a plug-in component to the Eclipse Platform. The installer provided by Syclo includes: Eclipse Platform - Ganymede (v3.4) release. The Agentry Editor plug-in for Eclipse. The Java Runtime Environment (JRE) version 1.6 (Java 6). The Microsoft Visual Studio C++ Runtime Libraries
Of these components, the Eclipse platform and the Agentry Editor plug-in are always listed in the installer as options to install. The JRE will be listed if it is not currently present. If already installed, this installer will not attempt to reinstall it. The C++ runtime libraries are installed in the background if not already present. If upgrading an existing Eclipse Platform, the current Eclipse implementation should not be installed from the Syclo-provided installer. Rather, the Eclipse components should be upgraded using the Eclipse upgrade framework provided on the Eclipse web site. This should be done before the Agentry Editor installer is run. Once the upgrade has been completed, the installer should be run and the option to install the Eclipse Platform should be disabled. Procedure
64

1. Launch the Agentry Editor installer executable. The Welcome screen will display.
2. Click the [Next >] button to advance the wizard. The next screen displayed is the License Agreement. Click the [Yes] button to accept the license agreement and advance the wizard.
3. The component selection screen is now displayed. Here, select the proper components to install for the Agentry Editor plug-in. If an existing Eclipse environment is to have the Agentry Editor plug-in added then uncheck this option. For a new installation, all components should be selected. Note that the Agentry Editor plug-in is always selected. Also note that if the Java Runtime Environment version 1.6 is not found, an option will be listed in this screen to install

it. In this case, the JRE will be installed to the default location.
65
Once these options have been selected click the [Next >] button. 4. The Destination screen will now be displayed. Here you select where to install the Eclipse environment and the Agentry Editor plug-in.
The proper selection here depends on the components selected to be installed. If Eclipse Ganymede was installed or upgraded prior to running the Editor installer, the proper selection here is the installation folder of that Eclipse installation. If the Eclipse environment is being installed here, the default location can be used or any other valid path may be selected. Once the proper path has been entered click the [Next >] button.
66

5. The next screen displayed provides options for include shortcuts for the Eclipse installation, which will be started with the Agentry Editor plug-in loaded.
Check the boxes that apply to the desired shortcuts for the installer to create. Click the [Install] button to begin the installation.
67
6. At this point the installation will proceed and the status will be displayed. You may click the [Show Details] button on this screen to view the detailed progress of this process.
7. Once the installer has completed its processing, the following screen will be displayed.
From here you can choose to start the Eclipse environment with the Agentry Editor plug-in. If this is the first time Eclipse has been installed and the Java Runtime Environment is not a part of your systems Path variable, do not start Eclipse here. Uncheck the box and click the [Finish] button. A final step in this task is necessary before starting the Eclipse environment.
68

8. If JRE was added to the host system as a part of the Eclipse and Agentry Editor installation, there are two folder locations that may need to be added to the systems Path environment variable. To add these, right click on the My Computer icon on the desktop and select the Properties item in the menu displayed. In the System Properties screen select the Advanced tab. Here, click the button Environment Variables. In the lower half of the screen now displayed is a list of the System Variables currently defined. Select the item Path in this list.
Click the Edit button and in the screen now displayed and check for or add the following two paths to the existing values. If they are already present, do not add them again. If they are not found, add them as listed below. NOTE: Take caution not to modify any existing values in this list. When adding path values here be sure to separate each path with a semi-colon (;).
C:\Program Files\Java\jre1.6.0_07\bin

C:\Program Files\Java\jre1.6.0_07\lib
69
Click the [OK] button when these values have been added. Then, close out of the system properties screen by clicking in the [OK] button. The Eclipse environment with the Agentry Editor plug-in can now be started.
Result The Eclipse environment, Agentry Editor plug-in, and any other components selected are now installed on your system. Additional configuration is needed within Eclipse related to the Agentry Perspective. After Completing This Task Additional configuration of Eclipse is needed as it relates to the Agentry Editor plug-in. This configuration is performed within the Eclipse Platform. This includes the following general items: Agentry projects work with several file types. File associations within Eclipse need to be created for these types to allow the platform to properly handle, display, and edit them. Script files, including SQL and shell or batch scripts created in the Agentry Editor are saved with a Unicode encoding. The default file encoding for an Eclipse workspace is different. File encoding options must therefore be modified within the Eclipse preferences. When working with a database back end system the Data Source Tools installed with Eclipse must be configured in order for the Agentry Editor connector studio to work with a database back end.
It may also be necessary at this point to complete the configuration of one or more Agentry Servers. With the release of version 5.0 of the Agentry Mobile Platform, a publish from the Editor is a part of the Server configuration process as it relates to the Agentry application projects system connections. If connectivity has already been configured between the Agentry Server and the back end system, the publish will not be necessary for connection configuration.
70
Importing a New Agentry Project Into the Eclipse Workspace

Prerequisite The following items must be addressed prior to performing this procedure: Determine the source of the application project to be imported and verify access to that source. Verify that the application project source to be imported is one created with the same or earlier version of the Agentry Mobile Platform. Projects, export files, or published applications created with a later version cannot be imported into an earlier version. Verify the workspace to which the project will be imported is the currently opened workspace in Eclipse. Determine a name for the project as it will be listed in the Eclipse workspace, as this is required information entered in the import process. Determine a name for the Agentry application project as it will be set in the Name attribute of the application definition, as this is required information entered in the import process. Though not required, it is strongly recommended that the Agentry Development Server to which development publishes will be performed is installed. While the location of this Server instance is optional during the import, it is necessary information when defining any of the synchronization logic within the project after it has been created.
Procedure Overview This procedure describes the steps involved in importing an application project into the current Eclipse workspace. When this procedure is completed a new Agentry application project will have been created in the current Eclipse workspace. This project will contain the definitions and application components found in the import source. Note that this process excludes any related projects for the source application that may reside in that source projects workspace, such as Java development projects and related packages. Such projects and components should be imported according to the process that match that project type and using tools found in Eclipse to serve this purpose. Perform this procedure to accomplish the following: Checkout an Agentry application project from an Agentry share repository, creating a new local project based on the tip revision within that repository. Migrate an application project from one workspace to another. Upgrade an application project or application export file created in a previous release of the Agentry Mobile Platform. Restore or recover an application project from an archived project or export file. Restore or recover an application project from a mobile application published to the Agentry Server
Procedure 1. If not already open, open or create the Eclipse workspace to which the new project is to be imported. Opening or creating a workspace in Eclipse begins by selecting the menu item File

| Switch Workspace and following the on-screen instructions.
71
2. Begin the import process by right-clicking an empty area in the Project Explorer View and selecting the menu item Import... . Alternately, select the menu item File | Import... in the Eclipse menus. Either item will display the Select Import Source screen:
72

3. Within this screen are the different import sources for Eclipse. Two of these pertain to Agentry application projects: Agentry Project and Agentry Share. Select the desired source by expanding one of these nodes and selecting the appropriate item under it. Click the [Next >] button to proceed. This displays the Select Source Import Wizard screen. This screen will be slightly different depending on the selected import source type. The following example is for a source type of Agentry Server application:
4. In this screen the information entered is somewhat dependent on the source type selected previously. Enter the information according to the following: a. The specific item selected for the source will be different based on the type. Select this source by clicking the Browse button. b. The Source Application box is only displayed when the source type is an Agentry Server. This lists the name of the application published to that Server instance. If the selected server instance is a Production Server, each published version currently residing on that Server is listed and any one of those versions can be imported. c. The Application Name is the name given to the mobile application to be created by the import. This is set as the value of the Name attribute within the application definition and can contain no white space. This field is read-only if the selected import source is an Agentry share repository. d. The Project Name is the name for the project within the Eclipse workspace. This must be a unique project name for the workspace and can contain white space. e. The Agentry Development Server for the application project being created. Any script files contained in the source project will be copied to this server. By default this field is set to the server from which the import is being performed, if that server instance is a
73
Development Server. This option can be left set as is if this is to be the Development Server for the new project, or it can be changed to a different Development Sever if necessary. 5. Verify the information entered is accurate and complete. Click the [Finish] button to perform the project import. A new project is now created by importing the definitions from the selected import source. The project is listed in the Project Explorer View and is open. Result After this process is complete, the new project is added to the Eclipse workspace. The project is opened and displayed in the Agentry Perspective within Eclipse. The application and project name will match those values entered in the Import Wizard. If the application project source was created using a previous version of the Agentry Mobile Platform, the new project has been upgraded during the import to the version of the current Agentry Editor. If the selected import source was an Agentry share repository, the new project contains the definitions found in the tip revision of that repository. The revision has been checked out to the current user. Subsequent changes made to the application project are tagged with that user ID. The project is connected to the selected share repository and can be updated fromit. Changes made locally can be committed to this repository.
Installing the Work Manager Client
75
Windows CE SMART Client Installation

Procedure Overview The SMART Client for Windows CE requires that the Windows CE device is physically connected to the PC using its docking station and that ActiveSync has created a connection. This InstallShield application will install the client application created to run on any one of the supported Windows CE devices. This includes Handheld PC and PocketPC devices. To install the SMART Client: Procedure 1. Launch the installer executable file from the installation CD. The Welcome screen will display.
2. From the Welcome screen, click Next to begin Installing the SMART Client. The Setup Type window will display.
76
3. From the Setup Type window, select the option that matches your device. If your device is not equipped with a built in scanner, select Win CE device with out scanning. Click Next to continue. The Secure Data Selection window will display.
4. From the Secure Data Selection window, choose one of the following: Non-Encrypted Client Data** Encrypted Client Data**
Click Next to continue. The Start Copying Files window will display.
77
5. From the Start Copying Files screen, review your selections and input before continuing. To review or change any of you selections, click Back . When all selections are correct, click Next to begin the installation. A notice window will display, asking where to install the client. 6. When prompted, select the default for the device by clicking Yes . The installer will install the client to the target device. When installation is complete, the following prompt will ask you to check the target device to see if additional steps are necessary to complete the installation.
7. Check the target device for any addition steps. Click OK to complete the installation. Note: The device usually requires confirmation for the installation. Actions may vary depending on device. The Installation Wizard will install the SMART Client. When complete the Install shield Wizard Complete screen will display. 8. Click Finish to complete the installation.
78
Windows 32 SMART Client Installation

Procedure Overview In addition to the mobile client, there is also a client for the SMART Client application for Windows systems. To install the Windows client: Procedure 1. Start the Win 32 client installer. 2. Click Next on the Welcome screen. 3. In the next screen, select the installation destination for the client, or keep the default location, and then click Next . 4. In the Setup Ready screen, click Next to begin the installation. 5. When the installation is complete, click the Finish button in the final screen of the installer. Result When this is complete, the SMART Client for Windows will be installed.
Security Features and Specifications
80
Web Application Security in Netweaver AS ABAP

The SMART Mobile Suite Administration Component is a web application based on Web Dynpro for ABAP. Netweaver AS ABAP supports various logon scenarios such as basic authentication, and logon ticket. Basic authentication requires the user to enter a user name and a password when the web application is launched for the first time. Weak encryption technique is used during data transmit. Therefore Syclo strongly recommends enabling SSO2 in Netweaver AS ABAP to allow logon ticket. For information on how to configure authentication using logon ticket in Netweaver AS ABAP, please refer to the manual User Authentication and Single Sign-On on the SAP Help Portal. Example link is provided below:
http://help.sap.com/saphelp_nw04s/helpdata/en/5c/b7d53ae8ab9248e10000000a114 084/frameset.htm
81
SAP ERP Authorizations for Mobile Users

All mobile users will need the following minimum authorizations in order to be able to connect to SAP ERP through the Work Manager Server.
S_RFC Object
The following rights are needed for the S_RFC object: Activity: Execute Name of RFC: RFC1 SDIFRUNTIME SYST SG00 SRFC SYSU /SYCLO/*
Type of RFC Object: Function Group
P_PERNR Authorization Object

The following rights are needed for the P_PERNR authorization object: Authorization Level: R Infotype: 0001 0002
Interpretation of assigned personnel number: * Subtype:
Addition Business Application Authorizations

Mobile users must have additional authorizations assigned in SAP in order to be able to perform activities such as create or change notifications, or to create or change work orders by using Work Manager. These additional authorizations will be implementation-specific.
82
Security Settings
These settings are used perform Authorization checks at various levels of mobile data object process. The security checks are carried out by the Syclo integration framework at runtime. Security check rules can be defined at 3 different levels: System Security: These checks are application independent and apply to all components of Syclo Integration framework. There are no prerequisite rules defined for system security. Product Security: These checks are performed at product level, meaning the Application dependent checks. There are no prerequisite rules defined for the product SMART 2.0 Syclo Class Handler Security: These checks are performed at the data object class handler level. You can perform these authorization checks at individual mobile data objects at runtime. There are no prerequisite rules defined for class handler objects.
83
Overview of Security Features in Agentry

There are numerous security features available within the Agentry Mobile Platform. In general terms, these security features can be organized into two categories. First are those built into the platform and that may require configuration during implementation. Second are those that are a part of the application deployed on Agentry and are a part of the application definitions and components. Here, the first group, those security features built into the Agentry platform, are discussed.
Client-Side Data Encryption

As an option when installing the Agentry Clients the installation wizard provides the option for either the encrypted or non-encrypted Client. This option refers to how data is stored on the client device. The encrypted client will encrypt all production data stored on the client device. The Client will also encrypt all application data. Note that when the Encrypted Client is installed, there are additional items related to users that must be addressed. Specifically, if devices are shared among multiple users, when a user change occurs all production data and application data stored on the client device is discarded. Encryption of application and production data is based on the users login information. When this information changes, the previous data cannot be decrypted. This will be an issue in the event the previous users production data includes pending transactions (those not yet transmitted to the Server). If these transactions are not transmitted prior to changing users, they will be discarded. Any data captured by these transactions will be lost. If such transactions exist, a warning message is displayed when a new user logs into the Client and prior to the removal of the transactions. Since all application data is also removed, a new user of a Client must perform a transmit to retrieve all application and production data, similar to an initial transmit. Because of these facts, it is recommended that devices running encrypted Agentry Clients not be shared unless absolutely necessary.
SSL/TLS Encrypted Client-Server Communications

Since the release of Agentry version 4.4 a secure communications protocol has been made available called the Agentry Next Generation Encryption Layer, or ANGEL. This protocol uses SSL/TLS over TCP/IP communications to encrypt all data synchronized between the Clients and Server. The ANGEL protocol is selected as the connect type for a transmit configuration definition within the application. As of Agentry version 4.4 this is the default connect type for all transmit configuration definitions. The encryption strength supported is up 512 bit encryption. By default, the actual encryption strength between any given Client and the Server may be less than this, as certain older devices do not support these key lengths. In this default configuration, the Server will negotiate with a Client to determine the maximum supported encryption strength of the device. It is possible to alter this behavior by setting both minimum and maximum encryption strengths the Server will allow. In this case, Clients not able to support the configured minimum will not be allowed to connect with the Server.
Client Password Encryption
84

The passwords entered by users during login to the Agentry Clients are encrypted based on an encryption key received from the Agentry Server. This key is the public key portion of a public-private key pairing generated by the Server. Because of this, Clients are tied to that Server after an initial transmit. It is possible to export a Servers encryption key and import it into other Servers, should Clients need to connect to more than one, such as in clustered environments. This encryption protects user passwords entered on Clients. The password value is stored and transmitted in encrypted form. It is decrypted by the Server when a Client connects and when read in by the Client during user login. In both cases, the decrypted value is not stored permanently and used only for validation of the user.
Client and Server Authentication Certificates

When using the ANGEL connect type, both the Agentry Server and the Agentry Clients can be configured to require authentication prior to commencing synchronization. In most cases, the Server authenticate is implemented. Client authentication is implemented less often, but is still fully supported. The Server uses the self signed certificate AgentryServer.pfx, which is installed with the Server. The Clients contain the certificate file AgentryTrustedCertificates.sst, again installed by default. This certificate directs the Server to use the Microsoft Enhanced Cryptographic Provider for the SSL/TLS secure communications provided with the ANGEL connection type. It is important to note that the AgentryServer.pfx certificate is not considered an authentication certificate, and is not generated by a certificate authority. For both Server authentication and Client authentication a certificate may be obtained from a certificate authority and installed to the Server or Client. These certificates are then stored on the client devices or host system for the Server, with the corresponding trusted certificate entries placed on the counterpart system.
85
Agentry Security Specifications Reference Encryption Specifications

The following table lists the various points at which data is encrypted within the Agentry Mobile Platform and the related default algorithms and cipher strengths. The columns for older client devices refer to those that do not support the Microsoft Enhanced Cryptographic Provider. For these devices the Microsoft Base Cryptographic Provider is used. Client-side data encryption specs are the same for all supported devices.
Data Encryption Client Password Client-Server Data Transmission Client-Side Data Encryption
Key Exchange Algorithm & Strength RSA - 1024 bit RSA - 1024 bit
Encryption Algorithm & Default Strength RC4 - 128 bit RC4 - 128 bit
Older Devices - Key Exchange Algorithm & Strength RSA - 512 bit RSA - 512 bit
Older Devices Encryption Algorithm & Default Strength RC4 - 40 bit RC4 - 40 bit
MD5 - 1024 bit
128 bit
Not applicable to Client-Side Data Encryption
Not applicable to Client-Side Data Encryption
Authentication Certificate Specifications

The following table lists the specifications for certificate encoding for authentication certificates stored on the Servers host system and client devices.
Component Agentry Server Windows Desktop Client Mobile Windows Client
Certificate Encoding Privacy Enhanced Mail (PEM) Privacy Enhanced Mail (PEM) Distinguished Encoding Rules (DER)
Encryption RSA - 128 bit RSA - 128 bit RSA - 128 bit
86
Authentication Certificates
By default, the self signed certificate AgentryServer.pfx is installed on the Agentry Server and the certificate file AgentryTrustedCertificates.sst is installed on the Agentry Clients. This default certificate directs the server to use the "Microsoft Enhanced Cryptographic Provider" The Microsoft Enhanced Cryptographic Provider uses the RSA cipher algorithm for key exchange with a default key length of 1024 bits. It uses RC4 for its stream encryption algorithm with a default key length of 128 bits. If the attached Client does not support the Enhanced key lengths, the Enhanced Cryptographic Provider can support the "Microsoft Base Cryptographic Provider." The key lengths can be increased or decreased in the Agentry.ini file. The minimum key exchange length is 512 bits The minimum stream encryption algorithm length is 40 bits.
Increasing the minimums can lock out any clients that do not support the required key length. The default security settings on the Agentry Server and Clients are designed to meet the requirements of most implementations. However Agentry does support other cryptographic providers if greater security is necessary. To use another cryptographic provider, Agentry will require a Server certificate from a certificate authority, The Agentry Client supports Server authentication. This allows the client to authenticate the Server. To enable this feature, Agentry requires a server certificate from a certificate authority. Syclo does not provide this certificate. The Agentry Server supports Client authentication. This allows the Server to authenticate each Client. To enable this feature, Agentry requires certificates for each of the Clients from a certificate authority. Syclo does not provide these certificates.
Authentication Certificate Creation for Agentry

By default, the self signed certificate AgentryServer.pfx is installed on the server and the certificate file, AgentryTrustedCertificates.sst, is installed on the clients. You can create your own Self Signed Certificate to replace these default certificates.
NOTE:
The PFX file on the server can be named any unique name. The .sst file on the client, however must be named AgentryTrustedCertificates.sst.
87
Creating a Self Signed Certificate Using OpenSSL

Procedure Overview To create your own self signed certificate you will need to install OpenSSL. OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1). You can download OpenSSL at: http://www.openssl.org/ To create your own self signed certificate using OpenSSL: Procedure 1. From a machine where OpenSSL is installed, open a command prompt and enter the following command:openssl req -x509 -days 365 -newkey rsa:<password> -keyout server-key.pem -out server-cert.pemWhere <password> is your password for the new certificate. This will create a Self Signed Certificate server-cert.pem. 2. Convert the certificate to a PFX file. In the command prompt enter:Openssl pkcs12 -export -in server -cert.pem -inkey server-key.pem -out <NewAgentryServer>.pfxWhere <NewAgentryServer> can be any unique name for the new PFX file. For example NewAgentryserver.pfx 3. Copy the PFX file into the directory the Agentry Server was installed in. 4. From the Agentry Server GUI, select Edit gConfiguration Settings . This will launch the Configuration settings window. a. Select the ANGEL Front End tab. b. Change authenticationCertificateStore to the name of the new PFX file. Double clicking the Value will allow you to enter a new name. c. Change the authenticationCertificateStorePassword to the password you set in the file. d. Click Apply to commit the changes to the Server. e. Click OK to close the window. 5. Create a copy of the file server-cert.pem and rename itAgentryTrustedCertificates .sst. 6. Copy the new AgentryTrustedCertificates.sst to the Agentry Client installation folder. This will replace the AgentryTrustedCertificates.sst file installed with the client. 7. Restart the Server and the client. 8. Log into to the sever using the client.
88
Creating a Self Signed Certificate Using Microsoft's Certificate Creation Tool

Procedure Overview Use Microsofts Certificate Creation Tool, which exists in Windows, to create a self signed certificate. For more information, refer to:
http://msdn.microsoft.com/en-us/library/aa386968(VS.85).aspx

To create your own self signed certificate using MakeCert: Procedure
89
1. Create a self-signed certificate to declare yourself an authority. Open a command prompt and enter the following command:makecert -b 01/01/1999 -r -pe -n "CN=< Certificate Name>" -eku 1.3.6.1.5.5.7.3.1,1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.3 11.10.3.1 -cy authority -sv AgentryServerAuthorityCertificate.pvk AgentryServerAuthorityCertificate.cer 2. Create a new certificate for the Agentry Server's authentication by entering:makecert -b 01/01/1999 -pe -n "CN=< Certificate Name>" -eku 1.3.6.1.5.5.7.3.1 -ic AgentryServerAuthorityCertificate.cer -iv AgentryServerAuthorityCertificate.pvk -sky exchange -sv AgentryServer.pvk AgentryServer.cer 3. Convert the certificate to a PFX file. In the command prompt enter:pvk2pfx -pvk AgentryServer.pvk -spc AgentryServer.cer -pfx AgentryServer.pfx -po Syclo -pi Syclo pvk2pfx -pvk AgentryServerAuthorityCertificate.pvk -spc AgentryServerAuthorityCertificate.cer -pfx <NewAgentryServer>.pfx -po Syclo -pi SycloWhere <NewAgentryServer> is can be any unique name for the new PFX file. For example NewAgentryserver.pfx 4. Create a signing certificate trust list by entering:makectl -u 1.3.6.1.4.1.311.2.2.3 AgentryServerAuthorityCertificate.cer AgentryServerAuthorityCertificate.stl signtool sign -u 1.3.6.1.5.5.7.3.3 -d "Root Certificate for Un-Authenticated Agentry Servers" -r "Agentry Server (Self Signed)" -f <NewAgentryServer>.pfx -p <password> AgentryServerAuthorityCertificate.stlWhere <password> is your password for the new certificate. 5. Create a trusted certificate listcertmgr -add -all -ctl AgentryServerAuthorityCertificate.stl AgentryTrustedCertificates.sst certmgr -add -all -c AgentryServerAuthorityCertificate.cer AgentryTrustedCertificates.sst 6. Copy the PFX file into the directory where the Agentry Server was installed in. 7. Copy the new AgentryTrustedCertificates.sst to the Agentry Client installation folder. This will replace the AgentryTrustedCertificates.sst file installed with the client. 8. Restart the Server and the client. 9. Log into to the sever using the client.
90
Creating CA Certificate for Agentry

Procedure Overview To create a CA certificate you will need to install OpenSSL. OpenSSL is an Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1). You can download OpenSSL at:
http://www.openssl.org/
To use your own CA Certificate, start this procedure at step 5 and substitute your own CA Certificate information. Procedure 1. From a machine where OpenSSL is installed, Set the SSLEAY_CONFIG environment variable to tell CA.pl where openssl.cnf is:export SSLEAY_CONFIG="-config ./openssl.cfg" 2. Next, Generate the CA certificate and storage area: a. b. c. d. e. f. In the command prompt, type the following command:./CA.pl -newca Press return for the CA certificate file name. When prompted, enter a strong password for the new CA certificate's key. When prompted, enter the certificate details It will then try to create the certificate with the newly signed key (using the openssl.cnf config) - you will have to give the password you entered above. The new cacert.pem file is located in:/etc/ssl/ca/cacert.pem
Note: The certificate that the script generated may not actually be marked as a CA certificate. If in the X509v3 Basic Constraints section, in the output, it states "CA:FALSE" the certificate will need to be regenerated. Use this command to regenerate the Certificate
openssl ca $SSLEAY_CONFIG -extfile openssl.cnf -extensions v3_ca -out demoCA/cacert.pem -days 3650 -batch -keyfile demoCA/private/cakey.pem -selfsign -infiles demoCA/careq.pem
91
3. To generate a certificate request, in the command prompt enter: ./CA.pl -newreqThis will generate a newkey.pem and a newreq.pem 4. To sign the certificate request, enter:./CA.pl -signThis will sign the request and generate a newcert.pem with the signed certificate. 5. Convert the CA certificate to a PFX file, enter:openssl pkcs12 -export -in newcert.pem -inkey newkey.pem -out <NewAgentryServer>.pfxWhere <NewAgentryServer> can be any unique name for the new PFX file. For example NewAgentryserver.pfx 6. Copy the PFX file into the directory the Agentry Server was installed in. 7. From the Agentry Server GUI, select Edit, Configuration Settings. This will launch the Configuration settings window. a. Select the ANGEL Front End tab. b. Change authenticationCertificateStore to the name of the new PFX file. Double clicking the Value will allow you to enter a new name. c. Change the authenticationCertificateStorePassword to the password you set in the file. d. Click Apply to commit the changes to the Server. e. Click OK to close the window. 8. Create a copy of the cacert.pem file and rename it AgentryTrustedCertificates.sst . 9. Copy the new AgentryTrustedCertificates.sst to the Agentry Client installation folder. This will replace the AgentryTrustedCertificates.sst file installed with the client. 10. Open the AgentryTrustedCertificates.sst file with a text editor. Delete everything before the following line:"-----BEGIN CERTIFICATE-----" 11. Save and close the file. 12. Restart the Server and the client. 13. Log into to the sever using the client.
Work Manager Server Utilities
93
Overview of the Agentry Server Utilities

When the Agentry Server is installed, there are certain additional executable files placed in the Servers installation folder. These items comprise the Agentry Server Utilities. These utilities are run from the command line. Following is a list of these utilities and a brief description of their purpose. Quick Password Encoder - This utility will encode the passwords stored in the Agentry.ini file for various purposes. Items such as the password for a SQL Database system connection, or the authentication certificate password used by the Server for SSL communications may be encoded, rendering them unreadable by humans within the configuration file. Agentry Key Migration Utility - The Key Migration Utility is provided to facilitate the migration of a system from one Agentry Server implementation to another. When a Client logs into an Agentry Server it is tied to that Server via its private encryption key. If it is necessary to allow a Client to connect to a different Server, or possibly to one of several different servers, the key migration utility is used to migrate the encryption key from one Server to another.
Each of these are designed to be run from the installation folder of the Agentry Server. The associated executables for each must not be moved from these locations.
94
Agentry Server Administration Clients

With the release of the Agentry Mobile Platform version 5.0 the administration and configuration of the Agentry Server is made easier with the new software components called the Agentry Administration Clients. An Agentry Administration Client is a tool provided with the platform software that allows for administration and configuration of a running Server instance. There are two separate Agentry Administration Clients available for use, both of which provide different interfaces to the same functionality. These are the Agentry GUI and Agentry Command Console Administration Clients. The Agentry Administration Clients allow for the configuration and administration of a Server instance running locally or remotely. The administration clients are installed with each Agentry Server instance and can also be installed separately via their own installation package. The following is a list of the features of the administration clients: Start, stop and restart local Agentry Server instances. Change configuration settings within the Agentry.ini file for running Server instances. Enable and disable log settings and roll log files to backup locations on demand. View information about the Agentry Server instance and the host environment. View information about users currently connected to the Agentry Server and log users out of the Server.
In addition to these common features, with the release of version 5.1 of the Agentry Mobile Platform, the Agentry GUI Administration Client also provides the ability to create Agentry Server clusters. A cluster will contain two or more Agentry Server instances, all of which will be deployed for the same mobile application. The Servers in a cluster are then configured at the same time through the Agentry Administration Client, ensuring consistency in configuration settings and their related behavior. Additionally, when publishing to an Agentry Server that is a part of a cluster, that published version of the application will not be loaded by the Server until all members of the cluster have received that version. Until this condition is met, the previous common published version of the application will continue to be used by the Server. The newest version will not be served up to the Clients during transmit until all Servers have received the new version. Note that once an Agentry Server is a part of a cluster, it can no longer be administered through the Command Console Agentry Administration Client.
Agentry Administration Client Behaviors

When anAgentry Administration Client is started, the behavior will depend on whether it resides in the same directory as the Agentry Server or if it was installed to a separate location. If a Server exists in the same folder, the Agentry Administration Client will attempt to start that Server. If the Server is already running, the Agentry GUI Administration Client will prompt you to connect to the running Server instance. The Command Console Client will not do this automatically, but can still connect via the connect command. If the Agentry Administration Client is installed to a different directory than any Server instance, you will need to connect it to the Server instance to administer it. If the Agentry Server is installed to the same physical host as the Agentry Administration Client, the Agentry Administration Client
95
can start the Server instance and connect to it if it is not currently running. If the Server is not on the same host, the Agentry Administration Client can connect to the Server only if it is running. It cannot start or stop a remotely installed Server.
Agentry GUI Agentry Administration Client

The Agentry GUI Agentry Administration Client allows for the administration of any running Agentry Server instance to which it has access. This includes Windows, Linux, and Unix Server implementations. The Agentry GUI itself must be running on a Windows system. This tool allows for point-and-click administration and configuration of the Server.
Agentry Command Console Agentry Administration Client

The Agentry Command Console Agentry Administration Client can connect to a Windows, Linux, or Unix Agentry Server instance. The primary purpose for the Command Console is to administer a Linux or Unix Server installation where a Windows environment is not available. The Command Console can run on both Windows and Linux host systems. This tool allows for administration and configuration of a Server via a command line interface.
96
Connecting the Agentry GUI Agentry Administration Client

Procedure Overview In order for the Agentry GUI Agentry Administration Client to configure an instance of the Agentry Server it must be connected to that Server. If the GUI Agentry Administration Clientis in the same directory as the Server, the Agentry Administration Clientwill start that Server instance and connect to it. If the Server is already running the Agentry Administration Client will prompt you to connect to it. Alternately, the currently running servers on the network that are configured to broadcast their existence will appear in the pane on the left side of the Agentry Administration Clients screen. Here, a server can be selected and connected to. The following procedure describes the manual process to connect to a running Server instance. To connect to one listed, right click that server in the list and select Connect. To connect to a Server instance installed to a different location from that of the Agentry GUI Agentry Administration Client and that is not listed in the detected Servers for the Agentry GUI Agentry Administration Client, the following steps should be followed. Procedure 1. Start the Agentry GUI Agentry Administration Client. 2. Select the menu option Server | Browse For Server... This will display a Windows File Dialog.
97
3. Navigate to the path for the Server instance and select the Agentry.ini file and click the [Open] button. If the Server is currently running the GUI Administration Client will connect to it. If the Server is not running, a prompt will be displayed to start the Server. Click the [Yes] button to start the Server and have the Agentry Administration Client connect to it. Result Once the connection has been established you can configure and administer the Agentry Server instance as needed. After Completing This Task Once the desired configuration or administration has completed you can disconnect the Agentry Administration Client from the Server instance by selecting the menu option Server | Disconnect From Server .
98
Using the Agentry GUI Agentry Administration Client

The Agentry GUI Agentry Administration Client provides the interface to manage and administer one or more Agentry Servers. For multiple Production Servers the Agentry Administration Client can create a cluster of two or more Server instances. When configured in a cluster, the Production Servers will be configured as a single set of server instances with all configuration changes populated to all cluster members in a single operation. This will keep the Servers in sync for a multi-server deployment. The areas of configuration and management that can be set for a single Server instance or a cluster of Agentry Servers includes: Editing configuration settings for back end communications. Editing system settings, including log file generation and management, and log rolling. Enabling or disabling transaction failure handling functionality. Editing ANGEL client-server communications. (Port settings and multiple network adapter settings can only be configured for individual Server instances, not for those in a cluster.) Viewing Agentry version, OS version, and connection information for each Server instance to which the Agentry Administration Client is connected. Starting, stopping, and restarting each Server instance running in the same host as the Agentry Agentry Administration Client. Creating clusters of Agentry Server instances for the same mobile application deployment. Viewing user information for each currently-connected user, and disconnect users from Servers.
Configuration Settings
To set the configuration settings of an Agentry Server using the GUI Agentry Administration Client, select the menu item Edit | Configuration Settings to change the configuration options. This will display the Configuration Settings screen:
99
Each tab in this screen displays a different configuration section for the Agentry Server instance. Values can be changed by selecting the row and the value column for the item to be modified. Once changes are made, they are applied by clicking either the [OK] or [Apply] button. Changes denoted with the exclamation point icon will require the Server instance to be restarted before they take affect. Servers running on the same host as the Agentry Administration Client can be restarted automatically. Servers on separate host systems must be restarted manually. The different configuration sections displayed here are discussed in detail in relation to the various areas of overall behavior to which they pertain.
Log Settings
The log settings that can be modified include enabling and disabling different log categories, setting the verbosity level, and specifying whether to create single log files in addition to the thread log files for a given log category. To set the log settings for an Agentry Server instance, select the menu item Edit | Log Settings in the Administration Client. This will display the Log Settings screen:
On this screen the different categories of log messages are listed and can be enabled or disabled. Enabling a log category is accomplished by changing the Level column for that log category from Off to the desired verbosity level. This will then begin writing that category of log messages to one or more processing thread log files. Additionally, the messages for a log category can be written to a single file, regardless of the processing thread. This is accomplished by setting the Separate File column to Yes. Note that this should only be done for Agentry Development Servers, or only for short durations of time on Agentry Production Servers. Writing all log messages for a given log category to a single file will impact Server performance. The category of log messages will differ based on whether the log settings are for a single Server instance or for an Agentry Server cluster. Also, different log categories will be listed based on the system connections in use for the implementation. Full details on each log category can be found beginning in the section Agentry Server Log File Management in the Agentry Implementation and Administration Guide.
100
Viewing Server Information

Using the Agentry GUI Agentry Administration Client it is possible to view information about an Agentry Server instance and its host system. To view this information, the Server instance must be running, and the Agentry Administration Client must be connected to it. Select the Agentry Server instance about which information is desired and then click the View menu item. Here, select one of the Agentry Info , OS Info , or Connection Info menu items to see the related information about that Server instance.
Starting, Stopping and Restarting Server instances

The Agentry GUI Agentry Administration Client can start an Agentry Server instance and connect to it, and can stop or restart a Server instance if already connected. These operations are limited to those Agentry Server instances running on the same host system as the Agentry GUI Agentry Administration Client. To start, stop, or restart a Server instance, select the Server in the list of those to which the Agentry Administration Client is connected and select the Server menu. Here, select the Start , Stop , or Restart menu items.
Creating Server Clusters

In deployments where multiple Agentry Servers are installed for the same mobile application in support of load balancing and failover, it is possible to create an Agentry Server cluster. Clustered Agentry Servers will have the following attributes: When publishing a new version of an application project to Servers in the cluster, none of the Server instances will load that version or make it available to the Clients until all Server instances have the same published version. When an Agentry Server starts it will compare its published version of the application to all others in the cluster and will not be able to join the cluster unless it is in agreement with the others. Changing configuration settings will affect all Agentry Servers in the Cluster at the same time. Certain Server-specific configuration options cannot be changed through the Agentry GUI Administration Client. These are normally limited to Client-Server communications settings listed in the ANGEL Front End Ports section. Log settings are applied to all Agentry Servers in the cluster with a single operation from the Agentry Administration Client. All Agentry Server instances within a cluster are organized together in the Agentry GUI Administration Client screen.
To create an Agentry Server cluster, all Server instances to be added to the Cluster must be running and the Agentry Administration Client must be connected to all Server instances. Creating the cluster begins with selecting one of the Server instances that will be in the cluster and selecting the menu item Server | Create Cluster . From here, all Agentry Servers running the same mobile application with the same published version will be listed as Servers that may be added to the cluster. One or more of these can be selected and each instance is given a cluster name, which is how it will be identified in the Agentry Administration Client. Once a Cluster is created, it is also possible to add additional Servers to the cluster by selecting the non-cluster member and then selecting the menu item Server | Join Cluster .
101
An Agentry Server instance may be removed from a Cluster by selecting the menu item Server | Leave Cluster .
Viewing User Information

Form within the Agentry GUI Agentry Administration Client, it is possible to view all users connected to any Agentry Server instance to which the Agentry Administration Client is connected. An individual user can be selected in this list and information about that user connection can be displayed. Select the menu item User | User Info to see this information. A user can also be disconnected from an Agentry Server instance by selecting that user in the Agentry Administration Client and selecting the menu item User | Disconnect .
102
Clustering Multiple Agentry Servers

Prerequisite Before following this procedure for creating the Agentry Server cluster using the Agentry GUI Agentry Administration Client, the following items must be addressed: Each Agentry Server instance must have the same published version of the mobile application. The Agentry GUI Agentry Administration Client must have network access to all prospective Agentry Server cluster members.
Procedure Overview In this procedure the steps for creating a cluster of multiple Agentry Server instances for the same application deployment are provided. This procedure will result in all Server instances selected being a part of the same cluster. These Server instances can then be configured and managed as a group using the Agentry GUI Agentry Administration Client. This procedure is applicable only to Agentry Production Servers. Development servers cannot be clustered. A cluster of Agentry Servers is created when multiple Server instances have been installed for the same mobile application deployment in which users may connect to any Server in the cluster for a given transmit. This is normally the case in support of load balancing and failover functionality. Procedure 1. Before creating the Cluster, each Agentry Server instance should be configured separately for its Client-Server communications. Specifically the settings in the ANGEL Front End Ports configuration section should be reviewed and set according to the network environment. These settings can be different for each Server instance based on the overall network environment. As such, they cannot be modified using the Agentry GUI Agentry Administration Client to contain different values once the Servers are a part of a cluster. These settings can be changed using the Agentry Administration Client prior to creating the cluster. 2. Start the Agentry GUI Agentry Administration Client, which will be the AgentryGUI.exe executable in any directly where the Agentry Server was installed. Alternately, the Agentry Administration Client may have been installed separately and can be run from that location as well. 3. When the Agentry Administration Client has finished starting, it will display a list of all Agentry Server instances it has detected. In this list, right click the first Server instance to be in the cluster and connect to it by selecting the Connect menu item. Repeat this procedure for each additional Server instance to be a part of the new cluster. 4. Once a connection has been made to all Agentry Server instances for the new cluster, right-click on any one of them and select the menu item Create Cluster . This will display the following screen where the name for the new cluster is entered and the

cluster members are selected:
103
5. In this screen, enter a name for the new cluster. This will be the name by which the Server cluster is identified in theAgentry Administration Client. In the list below this field are all the Agentry Server instances running the same version of the same application as the one selected at the beginning of this process. Select those Servers in this list by using Ctrl+Click that are to be added to the Cluster. Then click the [OK] button. This will display the Edit Cluster Info screen, where the information for the first Agentry Server instance to be added to the cluster is entered:
104
6. On this screen, enter the name for the Agentry Server instance that will be used to identify the Server within the cluster. Then enter a port number upon which the Server instance will listen for other cluster members to communicate with it. Once this is entered, this same screen will be displayed again, once for each Server to be added to the Cluster. 7. Once all Cluster members have been named and configured with a Port number, the Agentry GUI Agentry Administration Client will update the settings for all cluster members. It will then restart all Server instances in the Cluster. When this process is complete, a message similar to the following will be displayed:
8. Returning to the Agentry Administration Client, the servers will now be displayed grouped together within the cluster:
Result The selected Agentry Server instances are now clustered together. Configuration changes made through the Agentry GUI Agentry Administration Client will be updated to all Cluster members in a single operation. Published application versions will be kept in sync between the Server
105
instances, with none loading a new version of the application and serving to Clients until all cluster members have received it.
106
Changing Configuration Settings with the Agentry Administration Clients

Procedure Overview When changing the configuration settings within the Agentry.ini file for an Agentry Server you have the options of either editing this file directly or using the Agentry GUI Agentry Administration Client. Using the Agentry Administration Client, you can edit the settings within the Agentry.ini file and restart the Server when necessary. The Agentry Administration Client indicates which options require a Server restart when modified. It also indicates which options have been changed but not yet applied. For those changes that do not require a Server restart, the new settings will take affect when the changes are applied. This procedure outlines how to access the configuration settings within the Agentry GUI Administration Client, and how to navigate through and modify the available settings. Procedure 1. Display the Configuration Settings screen within the Agentry Administration Client by selecting the menu item Edit | Configuration Settings . This displays the Configuration Settings screen.
107
2. Within this screen each of the configuration sections are represented by tabs. When a tab is selected the configuration options within it are listed and can be modified. To modify a setting select the item in the list. Then click the item in the Value column. Depending on the option selected you can either enter a new text value for the setting, or select the proper setting from a drop down list.
3. Once a change is made the [Apply] button will be enabled. You can apply the changes made by clicking this button, or by clicking the [OK] button. If a change is made requiring a restart, the following prompt is displayed:
4. You can select the different tabs in the Configuration Settings screen to make changes to the different available configuration options. For system connections, only those system connections that have been defined will be available. The tabs will be named after the configuration section name in the Agentry.ini file. Result Once you have made changes, and possibly restarted the Agentry Server, the new configuration options will take affect. For those modifications that do not require a Server restart the changes made will take affect as soon as they are applied.
108
System and User Information in Agentry Administration Clients

Procedure Overview In addition to changing settings and managing log files, the Agentry Administration Clients also provide access to system and user information. System information includes both the host system and the Agentry Server itself. User information is available for any user currently logged into the Server. Procedure To view information about the host system using the Agentry GUI Agentry Administration Client select the menu item View | OS Info . This will display an informational screen similar to the following with information specific to the environment upon which the Server is running:
To view information about the Agentry Server and the Agentry environment, select the menu item View | Agentry Info. This will display an informational screen similar to the following with information specific to the Agentry environment:

To view information about a user, first select that user in the Agentry GUI Agentry Administration Client. Then, select the menu item User | Info .
109
This will display an informational screen similar to the following with information about the selected user.
110
Agentry Command Console Commands Reference

The following commands are available in the Agentry Command Console Administration Client. You may also list these commands in the Administration Client with the help command. You can find command-specific help by typing the command
help commandName Action Get information on the Agentry Server. Connect to a local Agentry Server Connect to a remote Agentry Server Syntax agentryInfo connect connect host path Description Returns information about the Agentry Servers host system. Connects to the Agentry Server instance within the same directory. Connects to an Agentry Server instance in a location other than the current directory. Path must be in UNC format: \\hostname\drive\folderName\... and enclosed in double quotes Closes the connection to the Agentry Server instance. The Server itself remains running. The Administration Client is disconnected. ALIAS: getConfig. Returns the current settings for the configuration section named as a the parameter. Includes the data type, limits, and requires restart flag for each setting. ALIAS: getConfigs. Returns the name of all sections in the Agentry.ini file that can be configured through the Administration Client. Returns the current settings of the named log file. Format for the current settings is a number and letter separated by a dot, as in 2.Y. The number indicates the verbosity level, from 0-5, where 0 is off. The N or Y flag indicates if the log messages should be written to a separate file. Returns the count and the names of all log message categories and sections that can be enabled or disabled.
Disconnect from Server
disconnect
Get Configuration Signifies
getConfiguration section name
Get all Configuration Sections Get Log File Settings
getConfigurations
getLog log name
Get the names of all logs
getLogs
111
Syntax Description Changes the log setting for the named log. logName is the name of the log as returned by getLogs. logLevel is a number, 0-5, where 1 is the leas verbose, 5 is the most, and 0 is disable. separateFile is Y or N to log messages to a separate file or not. This command must be followed by a saveLog command for log changes to be applied. Logs the given user out of the Server. userName must be as returned by getUsers Returns information about the operating system hosting the Agentry Server. ALIAS: exit. Exits the command console.
Action Change a log file setting
log logName=logLevel.sep arateFile
Log a user out of the server Get operating system information Exit out of the Command Console Administration Client. Stop and restart the Agentry Server. Roll Server log files to back up directory Save configuration changes
logOut userName osInfo quit
restart
Restarts the Agentry Server to which the Administration Client is connected. Will return error for a Server instance not on the same host. Rolls the log files generated by the Server from the Logs directory to a back up directory named LogsRolled\dateAndTime. Saves any changes made to the configuration settings made via the setConfigurationSection command. ALIAS: setConfigs. Sets the configuration setting in the specified section to the given value. This command must be followed by saveConfig in order for changes to be applied. Multiple setConfig commands can be applied with a single saveConfig. Shuts down the Agentry Server instance. Starts the Agentry Server instance in the same directory. Specifying a local path in UNC format will start the server at that location. Cannot start a Server on a remote host with this command. Returns a list of all users currently logged into the Agentry Server. Returns information on a currently logged in user. the user ID must be as returned by the users command.
rollLogs
saveConfig
Change a configuration setting.
setConfigurationSect ion section.key=value
Stop the Agentry Server Start the Agentry Server
stop start [path]
Get list of currently logged in users. Get information on current user.
users userInfo userId
112
Encrypt Password Utility Overview

The Encrypt Password Utility is used to encrypt the various passwords found in the Agentry.ini configuration file of the Agentry Server. Each configuration section containing a password value can have that password encoded by this utility. Running the encoder on the command-line will result in a series of prompts, one for each of the passwords to be encoded. You may select to encode the given password or not. If you elect to do so, the password value for the section is encoded. Additionally, each section has a configuration option indicating whether the password value is encoded. This option is set to false by default. The password encoder utility will set this configuration option to true. The following table contains a list of the configuration sections, the password option, and the encoded flag that the encrypt password utility modifies.
Configuration Section [Angel Front End]* [Web Server Front End]* [SQL-n] [HTTPXML-n]
Password authenticationCertificateStorePas sword authenticationCertificateStorePas sword dbConnectionPassword basicAuthenitcationPassword
Encoded Flag authenitcationCertificateStorePasswordE ncoded authenitcationCertificateStorePasswordE ncoded dbConnectionPasswordEncoded basicAuthenticationPasswordEncoded
*- These passwords will only be encoded if the configuration option authenticationCertificateStore is set to a value other than the default of AgentryServer.pfx. The password for this default certificate store cannot be encoded.
113
Using the Encrypt Password Utility

The encrypt password utility is run from the Windows command prompt and from within the folder where the Agentry Server has been installed. The utility is run via the command encryptPW, which takes no arguments. The user running the command must have read-write access for the Servers folder and all its contents, particularly the Agentry.ini configuration file. Prerequisite Prior to running the encrypt password utility, the following items should be addressed: Determine which passwords should be encoded within the Agentry.ini file. Obtain the proper passwords for each that is to be encoded, as you will be required to enter them when running the encoder utility. Determine the best time to restart the Agentry Server after this change is to be made. If using the AgentryServer.pfx file for either the ANGEL or Web Server Front End communications, the password for this certificate file cannot be encoded. The utility will not prompt you for the related password values.
1. Save a copy of the current Agentry.ini file to a backup location or file name prior to running this command. 2. Open a Windows (DOS) command prompt and navigate to the installation folder of the Agentry Server. 3. Enter the command: C:\Agentry\ServerProd\>encryptPW The following prompt will be displayed. Note that if one of the following sections is not a part of the Agentry.ini file, the prompt for it will not be displayed.
Configure ANGEL Front End? [Y/n]
4. If you wish to encode the password for this section, enter the character Y. Otherwise, enter n to skip this section. If you enter Y, the following prompt will be displayed: Please enter new password: Type the new password after this prompt and hit the Enter button. The password for the section will be encoded and the corresponding password encoded flag option will be set to true. You will then be prompted to encode the password for the next section.
114
5. Repeat this procedure until you have processed all sections within the Agentry.ini file. The utility will then exit, returning you to the Windows command prompt. 6. The Agentry Server must be restarted if currently running in order for these modifications to take affect. Result The password values you elected to encode will now be encoded within the Agentry.ini file. These values are no longer human readable. Also, the encoded password flag option that pertains to each encoded password will be set to true.
115
Server Key Migration Utility

The Agentry Server and Clients have a relationship via the public-private pairing used to encrypt the users passwords on the Clients. This pairing is unique for a given Agentry Server. This means once an Agentry Client successfully logs into a Server, it cannot log into a different Server until the Client is reset. There are circumstances when the Client must be able to log into a second Server, such as during migration. Also, in a load balancing or failover environment, the Client may connect with one Agentry Server during one transmit, and another during a second. In order for such environments to function, the Agentry Servers must all have the same private key. This is accomplished using the Server Key Migration Utility. This utility can export the private encryption key from one Agentry Server and import that same key into a second Server. When this is done, the original private key for the second Server is replaced with the one being imported. Another option with this utility is to remove the existing private key for the Agentry Server, forcing the Server to generate a new one. This may be necessary if you wish to undo a previous import of a key, or if you are changing the encryption strength of the public and private keys. This last may be necessary based on the version of Windows upon which the Server is running, or if older mobile devices are in use that do not support larger encryption key lengths.
116
Server Key Migration Utility Command Line Reference

The following lists the command line syntax of the Agentry Server Key Migration utility. This is followed by a description of each of the command line parameters.
AgentryKeyUtility -export=filename[-base64]|-import=filename[-base64]|-deletekey
One of: -export=filename; -import=filename; or -deletekey is required. -base64 is optional to the export parameter. If used during export it must be used when importing the same file. If -base64 is not specified during export, it cannot be used during import.
Parameter -export=filename
Description Required parameter to export the Agentry Servers private key to filename. The file is created in the same folder as the Agentry Server. Cannot be used in combination with -import or -deletekey. If -base64 is not specified, the file created is in binary format. Required parameter to import an exported private key file named filename into the Agentry Server. Cannot be used in combination with -export or -deletekey. The file will be found in the same folder as the Agentry Server. The file is assumed to be in binary format unless -base64 is specified. If this parameter is specified at export, it must be set at import. Optional parameter to the export and import parameters, specifying the key export file is to be exported in plain text or imported from a plain text file, respectively. If this parameter is not specified, the file is in binary format. Cannot be used with -deletekey. Required parameter to delete an Agentry Servers private key. Cannot be used in combination with -export, -import, or -base64. Specifying this parameter will delete the Agentry Servers private key and will force the Server to generate a new one. This action will result in any Agentry Clients that have previously synchronized with the Server being unable to do so again until those Clients are reset. This includes the removal of all application and production data. As a result, this parameter should be used only after all Clients have successfully synchronized and no further data is to be captured on those Clients until after they are able to be reset.
-import=filename
-base64
-deletekey
117
Exporting a Servers Private Encryption Key

Using the Agentry Key Migration Utility the Agentry Servers private password encryption key can be exported to a file, which can in turn be imported into other Servers. When running this utility, it must be executed from the same folder as the Agentry Server. Prerequisite Prior to exporting a Servers private key, you should determine the desired format of the export file created (binary or text) and the proper name for the new file. 1. Log in to the Windows host system for the Agentry Server with a user account that has administrator privileges. Then, open a Windows (DOS) Command prompt and navigate to the Agentry Servers installation folder. 2. To export the private key to a file, execute one of the following two commands: a. To export to a binary file: > AgentryKeyUtility -export=MyServersKey.ex b. To export to a plain text file: > AgentryKeyUtility -export=MyServersKey.txt -base64
Result Once the above command has been run, a file will be created in the same folder with the name specified. This file will contain the private password encryption key for the Agentry Server. This file may be copied or moved to other Agentry Servers for import.
118
Importing a New Private Encryption Key

Prerequisite Before performing this procedure, the following items must be addressed: Copy the password encryption key export file to the Agentry Servers installation folder. Determine the format of the export file, either binary or plain text. IMPORTANT: Verify that any Agentry Clients that may have previously synchronized with the Agentry Server do not have any pending data in need of transmit. If they do, have the users perform a synchronization with the server prior to performing this procedure. Any Clients that have synchronized with the Server prior to changing its password encryption key will not be able to do so again until after they have been reset. Resetting a Client removes all application and production data.
Procedure Overview This procedure describes the steps necessary to import a private encryption key to the Agentry Server. This process should be repeated for each Agentry Server instance to which the same group of Agentry Clients may connect. This will be necessary for running multiple Agentry Servers in a network cluster for the purposes of load balancing or failover. This is done from the installation folder of those Servers using the Key Migration Utility. Procedure 1. Log in to the host system of the Agentry Server to which the key will be imported using an account with administrative privileges. On a Windows system open a Windows (DOS) Command prompt and navigate to the installation folder of the Agentry Server. For Linux and UNIX systems change working directories to the installation directory of the Server. 2. From the Servers folder, run one of the following commands: a. To import a password encryption key from an export file in binary format: > AgentryKeyUtility -import=MyServersKey.ex b. To import a password encryption key from an export file in plain text format: > AgentryKeyUtility -export=MyServersKey.txt
Result Once the above command has been executed, the Agentry Server will have a new private password encryption key. This key will be used to generate public keys for Clients to encrypt and decrypt users passwords.
119
Deleting a Servers Private Encryption Key

Prerequisite Prior to deleting the Agentry Servers private encryption key, the following items must be addressed. IMPORTANT: Verify that any Agentry Clients that may have previously synchronized with the Agentry Server do not have any pending data in need of transmit. If they do, have the users perform a synchronization with the server prior to performing this procedure. Any Clients that have synchronized with the Server prior to deleting its password encryption key will not be able to do so again until after they have been reset. Resetting a Client removes all application and production data. If changing the encryption strength of the key, modify the publicKeyLength configuration option in the [Server] section of the Servers agenty.ini file.
Procedure Overview This procedure describes the steps necessary to delete the Agentry Servers private encryption key, forcing it to generate a new one. This may be done to undo a previous private key import, or when changing the encryption strength of the private and public keys. Note that if a Servers private encryption key is deleted, and an encryption key import was previously performed in support of multiple Server instances for the same application, this process will result in the Server having a different key. Procedure 1. Log into the host system for the Agentry Server with an account that has administrative privileges. On a Windows system open a Windows (DOS) Command prompt and navigate to the installation folder for the Server. On a Linux or UNIX system, change working directories to the installation directory of the Agentry Server. 2. Run the following command to delete the Servers private password encryption key: > AgentryKeyUtility -deletkey Result Once the above command has been executed, the Agentry Servers private encryption key will be deleted. A new private key will be generated by the Server when Clients log in, as will new public keys to be sent to those Clients.
Work Manager Server Log File Management
121
Agentry Server Logs Overview

The Agentry Server is capable of generating several log messages to be written to one or more log files. There are different categories of log file messages that pertain to a different aspect of the application: Client-Server communications System connection communications User-specific information for both Client-Server and System connection synchronization Definition loading and processing Code file (SQL, Java, batch files, etc.) processing, including post-SDML expansion and results, JVM messages, etc. Server system log files (These log files are always generated by the server and have no configurable behaviors.)
The log messages generated by the Agentry Server can be used to diagnose development or production issues, determine processing times for numerous aspects of synchronization, and to obtain various other pieces of information.
Agentry Server System Log Files

The following are the system log files for the Agentry Server: messages.log events.log startup.log shutdown.log
These log files are always generated and cannot be disabled. There contents do not have different verbosity levels.
Log Message Contents and Categories

Log files are enabled or disabled, configured, and managed using the Agentry Agentry Administration Client. The options available are to enable or disable the various log files, specify whether log files are generated based on a processing thread or more narrow areas of functionality, and the verbosity level of the log message contents. The log messages generated by the Agentry Server can be categorized as follows: Server - Messages generated resulting from Server processing. The contents here are a an inclusive set of the other categories, with the messages being all those related to any processing performed by the Server. User - Messages generated specific to a single user. The contents here are an inclusive set of the other categories, with the messages being all those related to any user-specific processing performed by the Server. System Connection - Messages generated resulting from processing performed by the Server for back end data synchronization for a specific system connection. The contents
122

in this category are messages that result from processing the various synchronization definitions within the application. Each system connection within an application has its own set of log messages that can be individually enabled and configured. Client Communications - Messages generated resulting from Client-Server communications. These messages include listing IP addresses and port numbers involved, the opening of sockets, the transfer of data in both directions, and the various messages sent between the Client and Server.
The contents of all log messages, regardless of category, include both error messages and informational and status messages. Each message includes a date and time stamp precise to the millisecond. The verbosity of the messages generated is configured when the category of log messages are enabled.
Log Messages vs. Log Files

The log messages generated by the Agentry Server are stored in log files. The messages and files, however, are not one in the same. When enabling and configuring the logging behavior of a Server, the contents of the log messages are configured. In addition, the files into which those messages are written is also configured. By default, when a log message category is enabled, those messages are written to a log file for a processing thread. Each Server processing thread will have its own log file containing all messages generated by the Server for processing within that thread and for the category of log messages that have been enabled. As an optional additional method for storing log messages, each category of log messages can be written to a category-specific log file. When this is enabled, all log messages generated by the Server for a specific category are written to the same log file, regardless of processing thread. The messages within the category-specific log files are grouped by the processing thread. This means a category log file will contain log messages resulting from processing related to that category. Following are the individual log files that maybe generated for each category, in addition to the thread log files: Server category : Server-ServerName.log where ServerName is the configured name for the Agentry Server in the Agentry - systemConnection configuration option. Agentry by default. User category : User-UserID.log where UserID is the users Client login ID. System Connection category : BackEnd-SystemConnection.log where SystemConnection is the name of the system connection section, e.g. SQL-1, Java-2, etc. Client Communications category : FrontEnd-Front End Type.log and ANGEL Connection-www.xxx.yyy.zzz.log where Front End Type is the connect type (e.g. ANGEL Front End, Web Front End, etc.). The second file is specific to the ANGEL Connection type. One file will be created for each Client where www.xxx.yyy.zzz is the Clients IP address as seen by the Server.
Note that configuring the log files to be generated separately based on the log message category will have an impact on Server performance, as multiple processing threads will be logging messages to the same physical log file. Only a single message can be written to such a file at a time. Therefore, each thread must wait until the file is available before it can write its log message to the file. It is recommended that configuring log files in this manner only be done for Agentry Development Servers with any regularity. It can be done in a production environment, but should only be done when necessary and for limited durations.
123
All log files are written to the Logs sub-directory of the Servers installation location. Log files are rolled periodically by the server, during Server startup or restart, and on command. The files are rolled to the sub-directory Logs-Rolled.
124
Events.log File
The events.log file records various Agentry Server events that occur at run time. These include startup and shutdown, opening and closing connections to the applications system connections, loading of Client-Server communications components, memory usage, thread expansion, and used and available storage. The events log will persist until one of the following occurs: The log files are rolled by the Server, at which point they are moved to a backup folder named elog. By default this occurs once every 24 hours provided the Agentry Server is running. With a change to the Servers configuration this file may also be moved to a back up location based on file size. The Agentry Server is shut down and restarted. In this case, the events log file is moved to the backup folder startups-yyyymmdd-hh24mmss. This occurs when the Server is restarted.
Unlike most other log files generated by the Agentry Server, the events log is always enabled. It cannot be disabled. The following is an example of the contents of the events.log file:
11/28/2005 15:11:01, 1, 3, 7, Thr 1912, Server, Agentry Configuration, userKey, aaaa, File: agentry.ini, C:\Syclo\agentry\system.cpp#2103:DTLoggerHandler::badKey11/28/2005 15:11:01, 0, 0, 2, Thr 1912, System Startup11/28/2005 15:11:01, 1, 3, 8, Thr 1912, Invalid server license: Invalid User Key, C:\Syclo\agentry\server.cpp#444:System Startup11/28/2005 15:11:01, 0, 11, 14, Thr 1912, TCP v4.0.0.011/28/2005 15:11:01, 0, 13, 14, Thr 1912, MID v4.0.0.011/28/2005 15:11:01, 0, 1, 4, Thr 1912, Agentry v4.0.0.0
NOTE:
Each log message is written to a single line. Space restrictions in the above example require some of the messages to wrap to multiple lines. Those items that ar a part of the message above it are tabbed in. Each message begins with a timestamp.
The first column of each message contains the date and time of the event being logged. The next three columns, separated by commas, are the message type, message group, and the message ID. The message type is always a 0 or a 1. A 1 indicates an error message, 0 indicates an informational message. These are then followed by the thread ID, denoted by the text Thr, and finally the message itself.
125
Messages.log File
The messages.log file contains log items related to client-server messaging, specifically each message and response sent to or from the Server. Each message and response sent between the Agentry Server and Client contains an item in this log. The information in each item includes the date and time of the message, the Clients IP address, the type of message or response, as well as other information. The messages log will persist until one of the following occurs: The log files are rolled by the Server, at which point they are moved to a backup folder named mlog. By default this occurs once every 24 hours provided the Agentry Server is running. With a change to the Servers configuration this file may also be moved to a back up location based on file size. The Agentry Server is shut down and restarted. In this case, the messages log file is moved to the back folder startups-yyyymmdd-hh24mmss. This occurs when the Server is restarted.
Unlike most other log files generated by the Agentry Server, the messages.log is always generated by the Agentry Server and be disabled.
Messages Log Format

The following is an excerpt from a typical messages.log file, with each column of output labeled. Following this example is a description of each output column.
Message State: A single character indicating the state of the message in relation to the Agentry Server. See the Message States and Push Message States tables later in this section. Message Code: A numeric value that identifies the type of message. See the table
126


Message Codes later in this section. Subsystem Code: This is always either a 1 or 20. This is a deprecated value that will only vary for older Syclo products built on Agentry 2.0 code libraries. Message Number: A number assigned by the Agentry Client that is incremented for each message sent. Date and Time: The data and time the message was received by the Agentry Server. This is always the date and time of the Agentry Servers host system. Response Code: A numeric code that indicates the response to the message. The message codes S and R each have a different set of possible Response Codes. For all other message codes the response code column is blank. Data Sent/Data Received: These two columns specify a running total of the amount of data sent and received by the server per message. This value is in bytes. User ID: The client ID of the user to which the message belongs. It is normal for the user ID to be blank for messages with a message state of I. Client Location: The IP address of the client device. It is normal for the Client Location to be unknown for messages with a message state of C.
The following tables contains the Message States for the messages.log file and their descriptions. There are two tables of message states. The first is for synchronous transmissions. The second is for asynchronous push messages only. Table 4: Message States - Synchronous Communications
State I Q S R C Name Incoming Queued Sent Response Received Response Complete Description Message in the process of being received from the client. Message has been decoded, the user has been identified, and the message is placed in one of the Agentry Servers work queues. The Agentry Server sent information and/or an acknowledgement to the client. A client response has been received by the Agentry Server. The message processing is complete.
Table 5: Push Message States - Asynchronous Communications

State O T L Name Outgoing Trying Linked Description A message is in the process of being sent to the client. The Agentry Server is attempting to connect to a client The Agentry Server has successfully connected to a client.
127
Description
State W R S C X F
Name Waiting Received Response Sent Response Complete Cancelled Failed
The Agentry Server failed in an attempt to connect to a client. It will attempt the connection again. The Agentry Server has received a client response. The Agentry Server sent information and/or an acknowledgement to the client. The message processing is complete. The Agentry Server cancelled the message to the client. The message has failed. The Agentry Server will not retry.
The following table lists the message codes, which indicate the type of message being processed or sent. These values are found in the Message Code column of the messages.log file.
Code 2 3 7 200 201 202 203 204 205 206 207 208 209 210 211 Client logout request Client login request Client user password change request
Description
Transaction instance sent to Agentry Server from client. Client has made a fetch processing request. Client system information message sent to Agentry Server. Client has requested an object be reloaded/refreshed. Client has requested the definition of an object be sent. Client has requested the definition of a fetch be sent. Client has requested the definition of a transaction be sent. Client has requested the definition of a screen set be sent. Client has requested the definition of an action be sent. Client has requested the definition of a rule be sent. Client has requested the definition of a report be sent. The Agentry Server has pushed an object and/or messages to the client.
128
Code 212 213 622 623
Description The client has sent an enable push message to the Agentry Server for the client user. Client has requested the definition of a style be sent. The client has requested all complex tables be updated. The client has requested all data tables be updated.
129
Startup.log File
The startup.log file contains messages generated by the Agentry Server during startup. The startup.log for the most recent Server execution can be found in the Servers folder. Previous startup logs are located in backup folders named startuplogs-yyyymmdd-hh24mmss. The folder is created at startup. The date and time stamp for this folder name is the current startup time. Its contents are the log files from the previous execution of the Server. Information in the startup log includes messages related to loading system connections, front end (client-server communications) components, connecting to back end systems, and other tasks performed by the Server during startup. The Agentry Server will always create the startup.log when it is executed. It cannot be disabled.
130
Shutdown.log File
The shutdown.log file contains messages generated by the Agentry Server during startup. The shutdown log for the most recent Server shutdown can be found in the Servers folder. Previous shutdown logs are located in backup folders named startuplogs-yyyymmdd-hh24mmss. The folder is created at startup. The date and time stamp for this folder name is the current startup time. Its contents are the log files from the previous execution and shut down of the Server. Information in the shutdown log includes messages related to disconnecting from system connections, front end (Client-Server communications) components, and other tasks performed by the Server during shutdown. The Agentry Server will always generate the shutdown.log when shutting down. It cannot be disabled.
131
Enabling Agentry Server Log Messages and Files

Prerequisite Prior to performing this procedure the following items must be addressed: If the Agentry Server for which the log files will be enabled is installed to a different host system from the Agentry Administration Client, the Server must be running. The Agentry Administration Client must be installed, either with the Server installer or via the Administration Clients installer. You must log in as a user with proper permissions to read and write to the directory containing the Agentry Server and its sub-directories.
Procedure Overview With the release of the Agentry Mobile Platform version 5.0, the Agentry Administration Clients are used to enable, disable, and configure the Servers log files. TheAgentry Administration Clients contain the interface to enable or disable each of the log messages categories and to specify whether the messages should be written to a separate log file. This procedure uses the Agentry GUI Agentry Administration Client. Procedure 1. Start the Agentry Administration Client and connect to the Agentry Server whose logs will be enabled. 2. Select the menu item Edit | Log Settings . This will display the Log Settings window:
132
3. Each of the logs listed here can be enabled or disabled. To enable a log, first select the related record for it. Then, click the Level item for that log record. This will display a drop down list with the options for the verbosity level of the log messages generated. Any selection here other than Off will enable the corresponding log.
133
4. Once the Level is selected, you have the option of recording the messages to a separate file. To enable this behavior, click the cell in the Separate File column for the selected log. This will display a drop down list with the options Yes and No, where No is the default. To write the log messages for the selected log to a separate file, in addition to the thread files, select the Yes item.
5. Once the desired selections have been made, click the [Apply] button to save the changes and leave the Log Settings screen option. Otherwise click the [OK] button to save the changes and close the screen. Result Once the logs are enable the thread files will be generated in the Logs directory for the Agentry Server. Alternately, the separate files for each log may be generated based on the options selected. After Completing This Task Once the log files have been enabled the information captured can be used for the purposes of debugging, issue tracking, and benchmarking, as well as many other items. Once the needed information has been captured, return to the Log Settings and set the Level setting to Off to disable the logs again.
134
SMART Mobile Suite Administration Component Logs

Application related logs produced by the SMART Mobile Suite Administration Component are stored in the standard SAP Application Log database tables. Configuration changes history made through ConfigPanel are recorded in the standard database table data change logs.
Accessing the Application Logs

Use standard transactions SLG1 or SLG2 to access and manage the logs. The transaction codes /SYCLO/SLG1 and /SYCLO/SLG2 will access the SMART Mobile Suite Administration Component log objects directly.
Application Log Objects

The SMART Mobile Suite Administration Component stores logs in the following objects and subobjects:
Log Object Log object /SYCLO/ Log Subobject /SYCLO/BAPI Log Subobject /SYCLO/EXCHANGE Description This log object stores all logs produced by the SMART Mobile Suite Administration Component. This log object stores logs produced by Syclo BAPI Wrapper and Mobile Data Object Class Handler This log object stores logs produced by Syclo Enhancement Implementation and Exchange Object Class Handler This log object stores logs produced by ConfigPanel This log object stores logs produced by administration and monitoring utility programs. This log object stores logs all other logs produced by the SMART Mobile Suite Administration Component.
Log Subobject /SYCLO/CONFIG Log Subobject /SYCLO/ADMIN Log Subobject /SYCLO/DEFAULT
Accessing Configuration Change History Logs

Use the standard transaction SCU3 to view the change history for the SMART Mobile Suite configuration settings. Parameter rece/client in the system profile must be set correctly in order for configuration changes to be recorded in the change history log.
135
Logged Customizing Object

Customizing Object Security Settings Description Customizing table SYCLO/SC001 Possible values for key field AuthChckLvl:
1 - System level security settings 2 - Mobile application level security settings 3 - Class handler level security settings
Key field Rec.No contains a numeric value identifying a security rule. Key field Item No. contains a numeric value identifying an attribute for a security rule.
10
Work Manager Backup and Restore Information
137
Backing up the SMART Server on a Windows Host

The SMART Server can be backed up using any method for backing up a Windows Server installation. Use the method your Network Administrator recommends. To fully back up a SMART installation: Back up the files located in the installations folder. The default directory is: Back up the Registry settings:
C:\SMART Service Manager for SAP\ServerProd My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Syclo
Back up java JDK and JRE installation and settings
138
Backing up the SMART Client

The SMART Client can be backed up using any method for backing up a Windows Mobile installation or a Windows 32 bit system. Use the method your Network Administrator recommends. To fully back up a SMART Client installation: Back up the files located in the installations folder. The default directory is:
C:\Program Files\Syclo\Service Manager \Program Files\Syclo\Service Manager
The client will then need to be installed on the mobile device using Active Sync once the restoration is complete. Windows Mobile devices can be backed up using any method your network Administrator recommends. For example, refer to: http://www.microsoft.com/windowsmobile/en-us/totalaccess/columns/protect-your-mobile-data.m spx
139
Backing up the SMART Mobile Suite Administration Component

Use standard SAP backup and restore procedures for the SMART Mobile Suite Administration Component. Specific procedures vary depending on the database for the SAP system. For information, please refer to the SAP Help Portal manual under Technical Operations for SAP Netweaver -> Database Administration. For example:
http://help.sap.com/saphelp_nw70ehp1/helpdata/en/ec/9e1802dd600947abafd22485 18697f/frameset.htm
11
Installation Trouble Shooting
141
Verifying Version Information Server Version

Version information for the SMART Server can be found in the Agentry.ini file. The Agentry.ini file is located in the directory the server was installed. Open the Agentry.ini file. Version information is located in the [Agentry] section:
[Agentry] messageLogFile=messages.log eventLogFile=events.log logMaxSize=0 logRollTime=1:45 logRollsAtTime=true systemName=SMART Service Manager Server v2.0.0.0
Client Version
Version information for the SMART Client can be found in the about.txt file. The about.txt file is located in the directory the client was installed. By default this is: Mobile Windows Devices
\Program Files\Syclo\Service Manager
Windows Desktops/Laptops/Tablets
C:\Program Files\Syclo\Service Manager
142
Agentry Platform Version

The SMART Server is built on the Agentry Platform. To find what version of Agentry the SMART Server is built from: From the Agentry Administration Client, click View and select Agentry Info .This will display Agentry info screen. The Agentry server version is listed on this screen.
The Agentry version can also be found on the Help-About screen. From the SMART Server, click Help and select About. This will display the About screen with the Agentry platform version .
143
SMART Server to SAP Connection Issues

SMART Server connectivity problems will manifest as error messages when you start the Server or as connect test failures, if you used the connectivity test after installing and configuring the Server. If this occurs, check the events log. The events log is the primary troubleshooting tool for connectivity issues. The events log lists either a SAP specific error code or SMART specific error message. If after installingthe Server and configuring the connection with your SAP system the connection test fails, or you received an error when starting the server, perform the following checks: 1) Verify that the Java classpath in agentry.ini is correct. 2) Verify that the Windows environment PATH variable is correct. 3) Try to connect to the SAP system from the SMART Server machine using the SAP interface, and verify the user name & password used to connect are correct. 4) Ensure that the client number and system number are correct.
144
SMART Server to Client Connection Problems

A Client connectivity problem will manifest as a: not all data transmitted, logging request failed message on the client. If this occurs, check the events log. The events log is the primary troubleshooting tool for connectivity issues. The events log lists either a SAP specific error code or a SMART specific error message.
Login request Failed

This error message results when the client device is not communicating with the SMART Server. To troubleshoot the above error message: 1) Make sure that the SMART Server is running 1) If the Server is not started, you will see the logging in message for a minute and eventually get this error 2) Check the events log to make sure that the SMART Server has not lost its SAP connection. Check for Network Issues

Time-outs and TCP/IP issues troubleshoot network Wireless Network Issues -- troubleshoot wide area network Firewalls configured ports must be open for the IP addresses of the clients
145
Incorrect User ID or Password

This error is seen on the handheld device when an incorrect User ID or Password is used. You will be able to view the error in the events.log file located in the install directory of the SMART Server. To fix the problem, have the Technician use the correct password.
Failure to Connect to the Server (3)

This error is received when the SMART Client fails to connect to the SMART Server. Because a connection to the server was not made, there will not be an entry in the events.log file. Common causes of this error are: The Clients network connection is not established or has been severed.
To fix the problem: Re-establish the computers network connection.
Communication Error (14)

The error below is received when the client cannot communicate with the SMART Server. Because there was a problem communicating with the Server, there will not be an entry in the events.log file. Common causes of this error are: The SMART Server service is not started. The network connection is not working properly. The device has Production logic on it and is now trying to connect to the Development server. This can be seen in the events.log file. Start the SMART Server service. Disconnect then re-establish the a network connection.
To fix the problem:
146
Error Messages
All communication between the SMART Server and the SMART Client are logged to a log file on the server named messages.log. A transmission from the SMART Client to the SMART Server is made up of many individual messages and each message goes through several States as it is processed by the SMART Server. A single line is written to the messages log for each state of each message per user. This log file is located in the directory the SMART Server was installed in. If the Server was installed in the default directory, it can be found here for the Production Server: Windows Host
C:\SMART Service Manager for SAP\ServerProd\Logs
Linux Host
/opt/syclo/SMART-SM-Server/Logs
The messages log is stored in the following location for a Development Server: Windows Host
C:\SMART Service Manager for SAP\ServerDev\Logs
Linux Host
/opt/syclo/SMART-SM-Server/Logs
147
Message Codes
Code 2 3 7 200 201 202
Description Logout Request Client logout from server Login Request Client login to server Change Password Request Client attempt to change password Object Transaction Client send of a single transaction to the server Object Fetch Client request for a Fetch to be run by the server and the result objects to be sent to the client Client System Info Notice Client specific information sent to server such as client hardware, OS, screen size, etc. Object Refresh Client request for server to send an updated copy of an object Object Definition Request Client request for an Agentry Object definition Fetch Definition Request Client request for an Agentry Fetch definition Transaction Definition Request Client request for an Agentry Transaction definition Screen Set Definition Request Client request for an Agentry Screen Set definition Action Definition Request Client request for an Agentry Action definition Rule Definition Request Client request for an Agentry Rule definition Report Definition Request Client request for an Agentry Report definition Object Push Server send of objects and/or messages sent to the client Enable Push Sent by client to enable push for this user on the server
203 204 205 206 207 208 209 210 211 212
148
Code 213 622 623
Description Style Definition Request Client request for an Agentry Style definition Complex Table Update Request Client request for all Agentry Complex Table updates Data Table Update Request Client request for all Agentry Data Table updates
Push Message States
State O T L W R S C X F
Name Outgoing Trying Linked Waiting Received Response Sent Response Complete Cancelled Failed
Description message in the process of being sent to client attempting to connect to client successfully connected to client failed attempt to connect to client, will retry client response received by server server sent information and/or acknowledgement to the client message complete message cancelled by server message failed, will not retry
Message States
State I
Name Incoming
Description message in the process of being received from client
149
Name Queued Description message has been decoded, user has been identified, and the message is placed in one of the servers work queues server sent information and/or acknowledgement to the client client response received by server message complete
State Q
S R C
Sent Response Received Response Complete

Syclo ImplAdmin Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Syclo ImplAdmin Guide

Încărcat de

Drepturi de autor:

Formate disponibile

smart WorkManager5.0.

SMART Work Manager for SAP ERP System Architecture Overview

SMART Work Manager for SAP ERP System Architecture Overview

Work Manager Overview

Creating a Paperless Workflow

SMART Work Manager for SAP ERP System Architecture Overview

Agentry Components for Product Name

SMART Work Manager for SAP ERP System Architecture Overview

Product Name Server

SMART Work Manager for SAP ERP System Architecture Overview

The Agentry Server in a Production Environment

SMART Work Manager for SAP ERP System Architecture Overview

The Agentry Server in a Development Environment

SMART Work Manager for SAP ERP System Architecture Overview

The Agentry Editor

Agentry Application Projects

Application Project Management

SMART Work Manager for SAP ERP System Architecture Overview

SMART Work Manager for SAP ERP System Architecture Overview

The Agentry Clients

SMART Work Manager for SAP ERP System Architecture Overview

The Agentry Test Environment

Mimicking Multiple Platforms

Test Script Recording and Playback

SMART Work Manager for SAP ERP System Architecture Overview

Work Manager System Requirements

Work Manager System Requirements

SMART Server System Requirements Overview

Supported Operating Systems

Functionality, Data and Resources

Work Manager System Requirements

Virtualization Software Support for the Agentry Server

Supported Versions 5.0, 5.5, 6.0, 6.5 All versions

Work Manager System Requirements

Agentry Server Hardware Requirements 32-bit Windows Server

Minimum Hardware Requirements

Users 100 or less 1

Dual Core Processors 4

Hard Drive Size (GB) 50

Work Manager System Requirements

Agentry Server Hardware Requirements 64-bit Windows Server

Minimum Hardware Requirements

Users 250 and less 500 1,000 2,500 5,000 10,000 1 2 4 6

Dual Core Processors 4 8 16 32 64

RAM (GB) 50 50 50 100 100 100

Hard Drive Size (GB)

Work Manager System Requirements

Agentry Server Hardware Requirements 64-bit Linux Server

Minimum Hardware Requirements

Users 250 and less 500 1,000 2,500 5,000 10,000 1 2 4 6

Dual Core Processors 4 8 16 32 64

RAM (GB) 50 50 50 100 100 100

Hard Drive Size (GB)

Work Manager System Requirements

CentOS and Red Hat Linux System Requirements

Work Manager System Requirements

Agentry Editor Hardware Requirements

Work Manager System Requirements

Agentry Editor Software Requirements

Work Manager System Requirements

Agentry Client Requirements

Agentry MDM Note

Windows CE 3.0, 2000, 2003, CE.net, and Windows Mobile 5 and 6