interaction mobilizer - amazon web services4ormat-asset.s3.amazonaws.com › vfs › 504902 ›...

Interactive Intelligence, Inc. 7601 Interactive Way

Indianapolis, Indiana 46278 Telephone/Fax (317) 872-3000

www.ININ.com

Interaction Mobilizer

Developer's Guide

Interactive Intelligence Customer Interaction Center® (CIC™)

Version 4.0

Last updated August 27, 2013

Abstract

Interaction Mobilizer™ enables connections between the customer’s mobile device or computer, the Customer Interaction Center (CIC), and third-party data sources. As an integrated application, Mobilizer provides a better customer experience by connecting more easily and directly with the organization’s contact center personnel and data. This document describes how to develop Mobilizer applications.

http://www.inin.com/

Interaction Mobilizer Developer's Guide 2

Copyright and Trademark Information Interactive Intelligence, Interactive Intelligence Customer Interaction Center, Interaction Administrator, Interaction Attendant, Interaction Client, Interaction Designer, Interaction Tracker, Interaction Recorder, ION, icNotify, Interaction Mobile Office, Interaction Optimizer, Insurance Content Management, and the “Spirograph” logo design are registered trademarks of Interactive Intelligence, Inc. Interaction Center Platform, Interaction Monitor, Customer Interaction Center, EIC, Interaction Fax Viewer, Interaction Server, Interaction Voicemail Player, Interactive Update, Interaction Supervisor, Interaction Migrator, Interaction Melder, and Interaction Screen Recorder are trademarks of Interactive Intelligence, Inc. The foregoing products are ©1997-2012 Interactive Intelligence, Inc. All rights reserved. Interaction Dialer and Interaction Scripter are registered trademarks of Interactive Intelligence, Inc. The foregoing products are ©2000-2012 Interactive Intelligence, Inc. All rights reserved. Messaging Interaction Center and MIC are trademarks of Interactive Intelligence, Inc. The foregoing products are ©2001-2012 Interactive Intelligence, Inc. All rights reserved. e-FAQ and Interaction Director are registered trademarks of Interactive Intelligence, Inc. e-FAQ Knowledge Manager, Interaction FAQ, and Interaction Marquee are trademarks of Interactive Intelligence, Inc. The foregoing products are ©2002-2012 Interactive Intelligence, Inc. All rights reserved. Interactive Intelligence Live Conference is a trademark of Interactive Intelligence, Inc. The foregoing products are ©2004-2012 Interactive Intelligence, Inc. All rights reserved. Interaction SIP Proxy and Interaction EasyScripter are trademarks of Interactive Intelligence, Inc. The foregoing products are ©2005-2012 Interactive Intelligence, Inc. All rights reserved. Interaction Gateway is a registered trademark of Interactive Intelligence, Inc. INTERACTION MEDIA SERVER IS A TRADEMARK OF INTERACTIVE INTELLIGENCE, INC. The foregoing products are ©2006-2012 Interactive Intelligence, Inc. All rights reserved. Interaction Desktop is a trademark of Interactive Intelligence, Inc. The foregoing products are ©2007-2012 Interactive Intelligence, Inc. All rights reserved. Interaction Message Indicator, Interaction Feedback, Interaction Process Automation, and Interaction SIP Station are trademarks of Interactive Intelligence, Inc. Deliberately Innovative is a registered trademark of Interactive Intelligence, Inc. The foregoing products are ©2009-2012 Interactive Intelligence Inc. All rights reserved. Interaction Web Portal, Interaction Analyzer, IPA, Latitude Software & Design are trademarks of Interactive Intelligence, Inc. The foregoing products are ©2010-2012 Interactive Intelligence Inc. All rights reserved. Spotability is a trademark of Interactive Intelligence, Inc. ©2011-2012. All rights reserved. Interaction Mobilizer is a trademark of Interactive Intelligence, Inc. ©2012. All rights reserved. The veryPDF product is ©2000-2005 veryPDF, Inc. All rights reserved. This product includes software licensed under the Common Development and Distribution License (6/24/2009). We hereby agree to indemnify the Initial Developer and every Contributor of the software licensed under the Common Development and Distribution License (6/24/2009) for any liability incurred by the Initial Developer or such Contributor as a result of any such terms we offer. The source code for the included software may be found at http://wpflocalization.codeplex.com. A database is incorporated in this software which is derived from a database licensed from Hexasoft Development Sdn. Bhd. ("HDSB"). All software and technologies used by HDSB are the properties of HDSB or its software suppliers and are protected by Malaysian and international copyright laws. No warranty is provided that the Databases are free of defects, or fit for a particular purpose. HDSB shall not be liable for any damages suffered by the Licensee or any third party resulting from use of the Databases. Other brand and/or product names referenced in this document are the trademarks or registered trademarks of their respective companies.

DISCLAIMER INTERACTIVE INTELLIGENCE (INTERACTIVE) HAS NO RESPONSIBILITY UNDER WARRANTY, INDEMNIFICATION OR OTHERWISE, FOR MODIFICATION OR CUSTOMIZATION OF ANY INTERACTIVE SOFTWARE BY INTERACTIVE, CUSTOMER OR ANY THIRD PARTY EVEN IF SUCH CUSTOMIZATION AND/OR MODIFICATION IS DONE USING INTERACTIVE TOOLS, TRAINING OR METHODS DOCUMENTED BY INTERACTIVE.

Interactive Intelligence, Inc. 7601 Interactive Way Indianapolis, Indiana 46278 Telephone/Fax (317) 872-3000 www.ININ.com

http://www.inin.com/


Contents Before You Begin ................................................................................. 5

Audience ......................................................................................... 5 Related Documents ........................................................................... 5

Links ............................................................................................ 5 Introduction to Interaction Mobilizer ................................................... 6

Interaction Mobilizer Users and Roles .................................................. 6 Developing Interaction Mobilizer applications using MSL ........................ 6

.NET Links ..................................................................................... 6 Boo Links ...................................................................................... 6

Interaction Mobilizer Development Tools .............................................. 7 Interaction Mobilizer System Architecture ............................................ 8 Development Environment ................................................................. 9 Testing Environment ....................................................................... 10 Production Environment ................................................................... 11

Developing Interaction Mobilizer Applications ................................... 12 Authentication and Identity .............................................................. 12

Facebook Authentication ............................................................... 13 Custom Authentication .................................................................. 13 Contact Center Customer Roles ...................................................... 13 Encrypting Data for Use with the Integration Service ........................ 14 Configuration MSL ........................................................................ 14 MSL Actions ................................................................................. 15 Interaction Mobilizer Configuration ................................................. 16

Developing HTTP Interfaces ............................................................... 17 Application Integration Interfaces ..................................................... 17

Initialization Webhook .................................................................. 18 Action Webhook ........................................................................... 19 Authentication Webhook ............................................................... 20 Common Response Guidelines ....................................................... 22

Setting Styles ..................................................................................... 24 Style Examples ............................................................................... 24 Field Styles .................................................................................... 24

Elements ..................................................................................... 24 Properties ................................................................................... 25

Implementing Mobilizer Chat ............................................................. 26 Scripting Chat in MSL ................................................................... 26 Creating a Chat Session ................................................................ 27

Setting Up the Front-End Server for Chat ........................................... 28 Getting Interaction Details ............................................................ 28 Updating Interaction Details .......................................................... 28 Getting All the Interactions ............................................................ 29 Deleting Interactions .................................................................... 29 Listing Current Chat Sessions ........................................................ 29 Connecting and Maintaining an XMPP Server Connection ................... 30

Mobilizer XMPP Bridge ..................................................................... 30 CIC XMPP Bridge............................................................................. 31

Push Notification Architecture ........................................................ 31 Publishing Mobilizer Client Applications ............................................. 32

Installing the Interaction Mobilizer Command Line Interface ................. 32 Interaction Mobilizer commands ..................................................... 32


Integrating Applications with Interaction Mobilizer ........................... 34 Integration Service Connections ....................................................... 34

Security Considerations ..................................................................... 35 Data Encryption in Mobilizer ............................................................. 35

Certificates .................................................................................. 35 Specifying Encrypted Fields ........................................................... 35

Scripting Tutorial ............................................................................... 36 MSL Background .......................................................................... 36

Getting Started............................................................................... 36 Editing Source Code ..................................................................... 37 Compiling and Publishing .............................................................. 37

Tutorial: Working With Text ............................................................. 38 Tutorial: Styling Text ...................................................................... 41 Tutorial: Adding Forms .................................................................... 44 Tutorial: Using Actions .................................................................... 46

Navigating with Forms .................................................................. 48 Conclusion ..................................................................................... 48

Appendixes .................................................................... 49 Appendix A: Mobilizer Configuration API ........................................... 50 Appendix B: Reporting and Data Tracking .......................................... 72

Raw Data ....................................................................................... 72 Raw Data Interfaces ..................................................................... 72 Raw Data Structure ...................................................................... 72 Events and Event-specific Data ...................................................... 73 Client changes ............................................................................. 76

Reporting Data ............................................................................... 76 Reporting Data Structure .............................................................. 76 Compiling Raw Data into Reporting Data ......................................... 80


Before You Begin Interaction Mobilizer gives mobile customers improved access to your organization’s contact center. Mobilizer provides an application development platform that you can use to develop mobile solutions, and the infrastructure necessary to publish applications and integrate them with Customer Interaction Center (CIC).

Audience Read this document if you are responsible for developing mobile applications or integrating any applications with Interaction Mobilizer. Interaction Mobilizer software developers must have experience working with Microsoft .NET and programming with Boo, Python, or another object-oriented script style language.

Related Documents The following documents include important information related to using Interaction Mobilizer: Interaction Mobilizer Installation and Configuration Guide Interaction Web Tools Technical Reference Interaction Web Tools Developer's Guide

Links For an overview of Interaction Mobilizer, see http://www.inin.com/mobilizer/.

http://www.inin.com/mobilizer/


Introduction to Interaction Mobilizer Interaction Mobilizer™ enables seamless connections between a contact center customer with a mobile device or computer, and contact center agents via Customer Interaction Center (CIC) and third-party data sources. Interaction Mobilizer (or just Mobilizer) is a set of web services and an application development platform that enables you to create mobile applications that integrate with a live contact center. Mobilizer-based applications provide a better customer experience by connecting them more conveniently and directly with your organization’s contact center personnel and data. See the Interaction Mobilizer System Architecture, Development Environment, Testing Environment, and Production Environment diagrams for illustrations of the components required to implement Interaction Mobilizer.

Interaction Mobilizer Users and Roles To integrate with other Interactive Intelligence applications, Interaction Mobilizer includes a number of conceptual user types. Interaction Mobilizer incorporates the following logical user roles:

• Mobilizer Developer • Mobilizer Administrator • Contact Center Manager • Contact Center Supervisor • Contact Center Agent • Contact Center Customer

Interaction Mobilizer further defines contact center customer roles to control access to specific application features. For more information, see Contact Center Customer Roles.

Developing Interaction Mobilizer applications using MSL Mobilizer Scripting Language (MSL) is an object-oriented script style programming language for the .NET Common Language Infrastructure (CLI). It is based on Boo, which uses a syntax similar to the Python language to complete programming tasks within Microsoft’s .NET Framework.

.NET Links Microsoft .NET is a framework for developing applications under Common Language Infrastructure (CLI) standard, specifying programming language and software environment standards. http://msdn.microsoft.com/en-US/netframework

Boo Links MSL is based on Boo, which is a free programming language with domain-specific language (DSL) extensions to help you develop Interaction Mobilizer applications. The Boo home page and Wikipedia entry provide a history of the language and programming resources. http://boo.codehaus.org/ http://en.wikipedia.org/wiki/Boo_(programming_language) Microsoft offers an IDE for Visual Boo in Visual Studio 2010. http://visualstudiogallery.msdn.microsoft.com/8d15c62f-de0d-42f0-863a-daa8330d977a

http://msdn.microsoft.com/en-US/netframework

http://boo.codehaus.org/

http://en.wikipedia.org/wiki/Boo_(programming_language)

http://visualstudiogallery.msdn.microsoft.com/8d15c62f-de0d-42f0-863a-daa8330d977a


BooLangStudio is a Visual Studio Industry Partner (VSIP) providing Boo integration with Visual Studio 2008. http://boolangstudio.codeplex.com/ SharpDevelop supports Boo development. http://boo.codehaus.org/Boo+AddIn+For+SharpDevelop Any plain text editing tool can also be used to develop Boo applications. TextMate offers a bundle for Boo syntax marking in both TextMate and Sublime Text 2. http://code.google.com/p/unityhelpers/downloads/detail?name=Boo-Textmate-v0.2.zip

Interaction Mobilizer Development Tools You can develop Mobilizer applications in Microsoft Visual Studio, SharpDevelop, and any plain text editor.

http://boolangstudio.codeplex.com/

http://boo.codehaus.org/Boo+AddIn+For+SharpDevelop

http://code.google.com/p/unityhelpers/downloads/detail?name=Boo-Textmate-v0.2.zip


Interaction Mobilizer System Architecture You can deploy Interaction Mobilizer with a number of different front-end features and back-end configurations. Mobilizer integrates with the existing Customer Interaction Center (CIC), back-end corporate systems including CRMs, and cloud-based services. To help you develop mobile applications, Mobilizer includes a Mobilizer-specific language (MSL). You can use MSL built-in functions to connect customers to the Mobilizer database and the Mobilizer integration service.

1. Customer-branded mobile presence – You can develop Interaction Mobilizer applications for

iPhones and Android phones. 2. Interaction Mobilizer front-end servers (Microsoft IIS) – Deliver configuration data to front-end

applications. Front-end servers are load balanced, with no server affinity. 3. Interaction Mobilizer database – Mobilizer uses a scalable, high-performance database for

temporary storage of application and tracking data. 4. Interaction Mobilizer application server – Hosts the Mobilizer application. 5. Customer Interaction Center (CIC) – Interaction Mobilizer uses existing CIC functions to queue

up interactions, get status, and interact with the contact center. 6. Interaction Mobilizer integration service – Provides data and interface functions between

Mobilizer applications and back-end and cloud-based systems. 7. Corporate back-end systems – Interaction Mobilizer can communicate with product catalogs,

ticketing systems, databases, and other sources and destinations of data for mobile applications.

8. Resource management systems – Interaction Mobilizer can integrate with the Microsoft Corporate Resource Management (CRM) system and other resource management systems.

9. Cloud-based services – Resources hosted in the cloud such as Salesforce.com can be sources or destinations of data for mobile applications.


Development Environment You can host the Interaction Mobilizer development environment on a single server using a virtual machine.

A. Single computer with four development virtual machines

1. Interaction Mobilizer front-end server. 2. Interaction Mobilizer database. 3. Interaction Mobilizer application server. 4. Interaction Mobilizer integration service.


Testing Environment You can create an Interaction Mobilizer acceptance testing environment using as few as two physical machines: one Web server and a one testing server hosting virtual machines for a database server, application server, and integration service. The final testing environment must be as close as possible to the actual production environment.

1. Customer-branded mobile application.

A. Single computer with a Web server virtual machine 2. Interaction Mobilizer front-end servers, load balanced with no server affinity.

B. Single computer with multiple testing server virtual machines 3. Interaction Mobilizer database. 4. Interaction Mobilizer application server. 5. Interaction Mobilizer integration service.


Production Environment You can implement an Interaction Mobilizer production environment using a minimum of: two front-end servers, two MongoDB replication instances and a MongoDB arbiter, an application server, two or more Customer Interaction Center servers, and two integration service instances.

1. Customer-branded mobile application. 2. Interaction Mobilizer front-end servers (N plus one), load balanced with no server affinity. 3. Interaction Mobilizer database (N plus one). 4. Interaction Mobilizer application server. 5. Customer Interaction Center (CIC). 6. Interaction Mobilizer integration service.


Developing Interaction Mobilizer Applications Your organization must create its own branded Interaction Mobilizer client applications. Contact center customers use the branded Mobilizer client application as their initial point of contact with your organization. Client applications work through Mobilizer to integrate with Customer interaction Center and other corporate or cloud-based resources. Interaction Mobilizer provides its own Mobilizer Scripting Language (MSL) based on Boo to help you develop Mobilizer client applications. See Appendix A: Mobilizer Configuration API for more information. This section describes how to develop your own Mobilizer client applications using the MSL. The individual topics contain an example of the code to provide the described feature.

Authentication and Identity Organizations can provide Interaction Mobilizer access as a public facing application with no login or authentication required. If so, continue to the Developing HTTP Interfaces section. If your organization requires identification and authentication of contact center customers, they must log on using one of the following methods:

• Log on using Facebook Authentication. • Custom Authentication requires your organization to define a set of unique identifying

information such a combination of account number, PIN, user name, password, security question answer, or other information.

Both forms of authentication require processing by the integration service. After Interaction Mobilizer authenticates the contact center customer, the system must also identify and authorize the user. Interaction Mobilizer only grants system access to authenticated contact center customers. A contact center customer is identified only when the system finds a unique identifier associated with the user credentials. A contact center customer is authorized only if the system can determine the rights associated with the user credentials. Your organization’s integration service must process authentication, identification, and authorization for each contact center customer. The Mobilizer front-end server gathers all information supplied by the contact center customer, such as a Facebook Access Token or custom authentication information, and submits it to an integration service. The integration service uses that information to authenticate the user, and returns the user’s identity and roles to the front-end server. By default, if an authentication is successful, the contact center customer is automatically granted the rights of an authenticated user role. The customer is also granted the rights of any roles included by the integration service configuration. In all cases, Interaction Mobilizer interprets the user credentials to determine which pre-defined roles are associated with the contact center customer. User roles control access to specific features within the application. Authenticating a contact center customer impacts the following system components:

• Clients Applications using Facebook Authentication • MSL Configuration • MSL Actions • Customer Integration HTTP API – for more information, see Developing HTTP Interfaces.


Facebook Authentication When authenticating through Facebook, the mobile application (iPhone or Android phone) performs the initial work to identify and accept log on credentials from the contact center customer. Facebook supports user authorization of applications. Interaction Mobilizer can access the authorization code to allow user authentication through Facebook. For more information, see https://developers.facebook.com/docs/authentication/. When deploying Facebook authentication, you can reuse the same Facebook Application ID that your contact center customers use to log on to your website or other applications. To avoid sharing the Facebook application App Secret with Mobilizer, perform Facebook authentication using the integration service as described in Developing HTTP Interfaces. The Mobilizer front-end server receives the authentication request with the Facebook user access token and queries the Mobilizer integration service to determine the identity of the user. If the integration service can identify the user, it responds to the front-end server with information about the identified user, including user roles. If the integration service cannot find an internal user record based on the Facebook ID, it responds with an HTTP 409 Conflict status code. If the Mobilizer client application receives this error, you can code the MSL to respond with a custom pre-defined action. You can display a form, change field visibility, or redirect the contact center customer to a custom authentication form.

Custom Authentication If you do not support Facebook authentication, use custom authentication. Custom authentication allows you to request specific login credentials. Credentials usually include user name and password, but can also include the contact center customer’s email, phone number, pass phrase, pin number, or other unique identifier. User credentials are the total of all data that your organization requires to authenticate and identify a user. Encrypt information at the client endpoint and decrypt information on an integration service. To all other parts of the system, user credentials are opaque and are not logged.

Contact Center Customer Roles Interaction Mobilizer provides specific contact center customer roles (called user roles in the code) to control access to different parts of the Mobilizer application. MSL scripts known as action handlers determine which parts of the application a contact center customer can access. MSL form configuration specifies the user roles required to access a form. User roles are not case-sensitive. Interaction Mobilizer supports two implicit contact center customer roles: anonymous and authenticated. All contact center customers begin in the anonymous user role. If an authentication request returns a valid user ID, Mobilizer changes the contact center customer role to authenticated. You can customize Mobilizer’s response to an authentication request so that it grants a specific set of roles to the contact center customer. For more information, see Developing HTTP Interfaces.

https://developers.facebook.com/docs/authentication/


Encrypting Data for Use with the Integration Service Encrypt data using certificates as follows:

• Encrypt data on the client side. • Decrypt data only using an Interaction Mobilizer integration service. • Code encrypted data to appear opaque and disable logging. • To differentiate between units, uniquely name each unit of encrypted data. • Secure data from man-in-the-middle interception by using signed certificates.

For more information about encrypting data in Mobilizer, see Data Encryption in Mobilizer. Encryption is not specific to authentication, and can be used for other actions such as secure credit card processing.

Configuration MSL The configuration MSL enables you to specify a login form, which is a special form type. There can only be one login form. If a Mobilizer front-end server detects two login forms, it writes a warning to the diagnostic log. The front-end server then recognizes and processes only the first form. In MSL, a login form is a specific type of form. You can customize it based on the authentication your organization requires. An example of a login: form 'the_login_form_id'

login title 'Our Company' grid 'login', 2

action_entry 'custom', 'do_login' label 'Login' image_uri 'our_company.png'

facebook_entry 'facebook', 'do_login' label 'Login with Facebook' image_uri 'facebook.png'

info 'login_heading', 'Our Company Credentials' text 'user_name'

required text 'password'

required password encrypted_with 'auth_key'

User Roles in Forms You can code forms in MSL to specify a required user role to view the form. Specify a required user role as follows: form 'form_id'

required_role 'customer' info 'This is some explanatory text.' text 'first_name'


MSL Actions MSL uses actions to accomplish tasks. An action is a unit of code that includes multiple operations in response to a user-triggered event. For example, you can call an operation to authenticate a contact center customer using webhook.Authenticate.

user object MSL actions access the user object to determine the current user information. If there is no authenticated user, this object is empty. During an unauthenticated session, data such as first name, last name, and email address is stored in the user object fields. For both authenticated and unauthenticated (anonymous) sessions, this data only persists during the current contact center customer session. You can also query the user object to check and manage user roles. To query roles, use the syntax user.IsInRole(“role_name”). The user object includes an IsLoggedIn property that you can query to determine whether the user is logged on. The list of properties and methods available in the user object:

Name Description UserId Gets the current user ID. UserName Gets or sets the current user name. Name Gets or sets the full name. FirstName Gets or sets the first name. LastName Gets or sets the last name. Email Gets or sets the email address. Description Gets or sets a description for the user. ImageUri Gets or sets a URI of an image for the user. Phone Gets or sets the user's phone number.

Extra A name/value pair string dictionary of extra information – use this field to store anything that doesn't fit in the other properties.

IsLoggedIn Returns true if authenticated, false otherwise. IsInRole(role) Returns true if the user has the specified role, false otherwise. Logout() Logs out the user – removes all roles and clears out all user information.

webhook.Authenticate method You can call the method webhook.Authenticate from any MSL action. The data passed to the integration service depends upon the context under which you run the MSL action. If a contact center customer presses a button or another standard form trigger starts an MSL action, the authentication request has the type custom. The authentication request contains the values of all form fields originally included in the submitting form. If you called the MSL action as the result of a special client-side authentication result, such as a Facebook login, the authentication request automatically includes data appropriate for the login. For example, in the case of a Facebook login, the authentication provider is facebook and the data includes the Facebook User Access Token. The response from the integration service determines the authenticated (or unauthenticated) state of the current user.


The webhook.Authenticate method can be called multiple times throughout a contact center customer’s interaction with the application. For example, consider a scenario in which a user logs on using Facebook, but has never configured an association between their Facebook account and your organization’s business accounts.

In this case, when the contact center customer starts Facebook authentication, webhook.Authenticate enables an integration service to validate the Facebook contact center customer and attempt to identify them. Because this contact center customer has no association between their Facebook account and their account with your organization, the user can be authenticated, but cannot be successfully identified. You can program MSL to display a form to the contact center customer that enables them to provide custom authentication credentials. When the contact center customer submits the form, you can instruct Mobilizer to send another webhook.Authenticate operation to authenticate the contact center customer using their custom credentials. Once authenticated, you can save the association between the previously captured Facebook user identifier and their newly identified contact center customer account. For all subsequent Facebook logins by this contact center customer, the system retrieves their user account without requiring another login.

Authenticate method details: Method name: webhook.Authenticate Method parameters

Name Description URL The URL for the authentication request.

customParameters Any custom parameters that need to be processed by this method during the authentication request. The custom parameters behave the same for any webhook.Post method calls.

To process the authentication response, pass a block of code to the webkook.Authenticate method. In MSL and Boo, these blocks are called closures. For more information about blocks of code, see http://docs.codehaus.org/display/BOO/Closures. The response indicates the success or failure of the authentication. A third possible response is authentication success but identification failure. For example: Facebook authentication succeeds, but Mobilizer cannot find a record of this user in the system. An example of the webhook.Authenticate action method, used in the do_login action: action 'do_login':

webhook.Authenticate("http://www.example.com/login") do(result): // result.Success <-- can use result.Success to determine if the authentication was successful or not // result.UnknownUser <-- can use result.UnknownUser to determine that the authentication was successful but we still don't know who the person is, for example with a Facebook login

end end

Interaction Mobilizer Configuration For more information, see the Interaction Mobilizer Installation and Configuration Guide.

http://docs.codehaus.org/display/BOO/Closures


Developing HTTP Interfaces You can extend Interaction Mobilizer using a small set of HTTP interfaces. Implement these HTTP interfaces using the web technology stack of your choice. To connect Interaction Mobilizer with these HTTP interfaces, call the webhook object from initializers and actions. Within Mobilizer, the group of HTTP interfaces are referred to as an integration service.

Application Integration Interfaces You can implement integrations and customizations to Mobilizer using a set of well-defined HTTP interfaces. The Mobilizer system issues HTTP requests to configured URLs and process the results. All supported requests and responses are listed in this section. All requests include an HTTP header indicating the current API version of Interaction Mobilizer. For example:

NGS-API-Version: 1.0.0

This version does not represent the Mobilizer server version, but rather the version of the webhook API. The integration service interprets the version to determine the expected JSON payload. The value is a version string that follows SemVer guidance. For more information, see www.semver.org. This section describes the following interfaces:

• Initialization Webhook • Action Webhook • Authentication Webhook • Common Response Guidelines

http://www.semver.org/


Initialization Webhook Call initialization webhooks from MSL code using an initializer to contact the Mobilizer front-end server. Mobilizer issues an HTTP POST request to the specified URL. The content-type of the request is application/json and the body is a JSON document whose format is defined in this section. The response must have a content-type of application/json and the body must be a JSON document formatted as defined in this section. It is acceptable to respond with nothing in the body, in which case the content-type header must be omitted.

Request Mobilizer issues a POST HTTP request. The content-type is application/json. JSON Body {

"customParameters" : { // optional, depending on whether the MSL specified custom parameters or not

"param1" : "param1 value", // all custom parameters are simple name/value pairs, no structured data is supported "param2" : "param2 value"

} } Some fields are optional and labeled as such. Known parameters

Name Description

customParameters A list of name/value pairs specified in the MSL that send metadata or other contextual information to the integration service. Used when a contact center customer or form trigger makes a webhook request.

Response If the HTTP status code is 200 OK, the Content-Type is application/json, and the body is a valid JSON document; the integration service processes the response from the front-end server. The response body must consist of the following JSON fields: {

"globalValues": { "id": "value", "id": ["array", "of", "values"], "id": { "hash": "of", "sub": "values" }

}

These values are populated into the global key-value store.

Response Example HTTP/1.1 200 OK {

"globalValues": { "pet_type_choices": ["Dog", "Cat", "Fish"]

} }


Action Webhook Call action webhooks from the MSL to process an action. Mobilizer issues an HTTP POST request to the specified URL. The content-type of the request is application/json and the body is a JSON document formatted as described in this section. The response must have a content-type of application/json and the body must be a JSON document formatted as described in this section. The body of the response can also be empty, in which case the content-type header must be omitted.

Request Mobilizer issues a POST HTTP request in response to an action webhook. The content-type must be application/json. JSON Body Some fields are optional, depending upon values of other fields. The optional are indicated as appropriate. {

"sessionId" : "74818bdc6b6440a59e1c3bfb3bd4f821", "userId" : "user1234", "formId" : "marketing_form", // The ID of the form that initiated the action "fieldId" : "submit_info", // The ID of the field that initiated the action "fields" : {

"first_name" : { // the name of a field that was submitted with the form to the server

"certName" : "auth_cert", // this field will only exist and have a non-empty value if the "value" field is encrypted. It specifies the named certificate that was used to encrypt the data. "value" : "encrypted field value, or plain text field value"

}, "last_name" : {

"value" : "Smith" }

}, "customParameters" : { // optional, depending on if the MSL specified custom parameters or not


} } Known parameters

Name Description

sessionId The current Mobilizer session ID for the client application instance. The Mobilizer client application must always provide the session ID.

userId The user ID of the current user. This field is optional and can be missing, null, or empty string. formId The form identifier of the containing form that triggered the action. fieldId The identifier of the field that triggered the action. fields A dictionary of all form fields and their values.

customParameters A list of name/value pairs that are specified in the MSL in response to a webhook request. Use this parameter to send metadata or other contextual information to the remote server.


Response The response from an action webhook must follow the common response formatting guidelines, specified in the Common Response Guidelines section.

Authentication Webhook Call authentication webhooks from the Mobilizer front-end servers as an MSL action. Mobilizer sends an HTTP POST request to the specified URL. The content-type of the request is application/json and the body is a JSON document formatted as defined in this section. The response must have a content-type of application/json and the body must be a JSON document formatted as specified in this section. The body of the response can also be empty, in which case the content-type header must be omitted. If the body of the response is empty, the result is interpreted as a failure to authenticate. For more information, see Authentication and Identity.

Request Mobilizer issues a POST HTTP request. The Content-Type is application/json. JSON Body Depending on values of other fields, some fields are optional and are indicated as appropriate. {

"sessionId" : "74818bdc6b6440a59e1c3bfb3bd4f821", "userId" : "user1234", "provider" : "facebook", // Valid values are listed in the following table "data" : {

// The information available in the "data" field depends on the provider. Provider-specific data fields are listed in the following table.

} } Known parameters

Name Description

sessionId The current Mobilizer session ID for the client application instance. The Mobilizer client application must always provide the session ID.

userId The user ID of the current user. This field is optional and can be missing, null, or an empty string. If provided, it indicates that an authentication request has succeeded for this user. It is possible to have multiple authentication requests per-user, depending on your Mobilizer application implementation.

provider The name of the provider for the authentication request. Supported values are: facebook and custom data An object that offers a set of values available for the specified provider.


Providers The following provider specification defines the supported providers and the JSON fields available for Facebook and Custom authentication.

Facebook Provider Value: facebook JSON Body {

"sessionId" : "74818bdc6b6440a59e1c3bfb3bd4f821", "provider" : "facebook", "data" : {

"accessToken" : "access token provided by facebook" }

}

Known parameters

Name Description

accessToken The Facebook access token that can be used to access the Facebook Graph API. For more information, see https://developers.facebook.com/docs/mobile/ios/build/#implementsso.

Custom Provider Value: custom JSON Body {

"sessionId" : "74818bdc6b6440a59e1c3bfb3bd4f821", "provider" : "custom", "data" : {

"formId" : "support_login_form", // the form that initiated the authentication request "fieldId" : "login_button", // the field that invoked the action which initiated the authentication request "fields" : { // the fields on the form and their values when the action was invoked

"first_name" : { // the name of a field that was submitted with the form to the server

"certName" : "auth_cert", // this field will only exist and have a non-empty value if the "value" field is encrypted. It specifies the named certificate that was used to encrypt the data.

"value" : "encrypted field value, or plain text field value" },

"last_name" : { "value" : "Smith"

} }

}, "customParameters" : { // optional, depending on if the MSL specified custom parameters or not


} }

Known parameters All known parameters in the data field are the same as the parameters specified in the preceding Action Webhook specification.

https://developers.facebook.com/docs/mobile/ios/build/#implementsso


Response The response from an authentication webhook follows the common response formatting guidelines, with the addition of a user field you can use to populate the user information: When responding with a 200 OK status code, include the "user" : { "userId" } field.

Common Response Guidelines Action and Authentication Webhook requests process responses using the following guidelines and format. The HTTP status code must indicate success or failure.

HTTP Status Code

Description

200 Success 401 Authorization failed

409

User authenticated against third-party provider, but not found in the internal system: for authentication requests, this value indicates that a third-party authentication was successful but no internal user could be found via the third-party user identifier. Typically, this value allows the user to associate their account with the third-party authentication information. For non-authentication requests, this value is considered an error condition.

500 Remote server generic error.

200 OK or 409 Conflict If an HTTP request does not generate a successful HTTP response, you do not need to provide a content-type or body. If the request does produce a successful response, specify the media type (via the content-type header) as application/json and the body must be a valid JSON document. The response can include of any or none of the following JSON fields: {

"clientValues" : { "id" : "value", "id" : ["array", "of", "values"], "id" : { "hash": "of", "sub": "values" }

}, "sessionValues" : {

"id" : <any valid JSON string, array, or hash> }, "user" : {

"userId" : "1234", "userName" : "joesmith", "name" : "Joe Smith", "firstName" : "Joe", "lastName" : "Smith", "email" : "[email protected]", "description" : "Gold Partner", "imageUri" : "http://www.example.com/images/customers/joesmith.png", "phone" : "800-555-1212", "roles" : ["customer", "partner", "admin"], // An array of strings that contain the names of roles the user is authorized for "extra" : { // everything under "extra" is arbitrary name/value pairs, values may be strings only.

"nickname" : "Joe", "preferredContactTime" : "afternoon" // etc...


} }

}

The following is an example response. When Mobilizer receives such a response, it updates the custom_value item in the session key-value store, sets the current user's email property to "[email protected]" and assigns them the customer role. {

"sessionValues" : { "custom_value" : "this is a custom value for use later"

}, "user" : {

"email" : "[email protected]", "roles" : ["customer"]

} }

401 Unauthorized, 404 Not Found, or 50x Internal Server Error (and related) If an authentication request fails, a resource is not found, or an unexpected error occurs, the media type must be application/json and the body must be a valid JSON document. If provided, the response body consists of the following JSON fields: {

"errorCode" : 1234, // integer representing a custom error code. 0 should represent no known error code "errorMessage" : "This error message should be presentable to an end user."

}

Sample test requests JSONs Login (Authentication Webhook)

{

"apiVersion":"1.0.0", "sessionId":"74818bdc6b6440a59e1c3bfb3bd4f821", "provider":"custom", "data": {

"username":"[email protected]", "password":"aabbzzx123"

} }


Setting Styles Mobilizer supports a subset of CSS formatting elements that you can use to set the look and feel of client applications. Styles and properties are listed in this section and Appendix A: Mobilizer Configuration API. Use styles to define the look and feel of screen elements. For Interaction Mobilizer, styles must be formatted [<element>[.<class>] ...] similar to cascading style sheets (CSS) but you cannot use #<id> to target individual elements. The names of CSS elements are based on the class naming of forms and fields in MSL. Within MSL, you can specify CSS class names for forms and fields in an optional properties dictionary. You can only use classes with forms and fields. Do not use classes with styled elements within fields such as label, detail, and text. Use typical CSS styles for these elements. Mobilizer interprets all other CSS styles normally, and automatically refreshes lists as needed. You can set background colors and images, and text area modal forms based on the form that pushed them. The Mobilizer client application sets styles when a form is pushed. Mobilizer does not automatically handle the callback style. Callbacks require special elements. Instead of using form, use callback_form and callback_detail for the element types. The callback_detail element defaults to the same styles set for callback_form.

Style Examples form {text-size:14} //applies to all elements in all forms

form.special {text-size:14} //applies to all elements in all forms of class special

info {text-size:12} //applies to all elements inside all the info fields

info.special {text-size:14} //applies to all elements inside info fields of class special

label {text-size:16} //applies to all label elements

info label {text-size:14} //applies only to labels in type info

Field Styles You can change the style for certain elements associated with each field, and some elements that are common to all fields.

Field Elements All Fields Label, Detail, Text

Elements Elements define a logical portion of the field where you can apply styles.

Element Properties Description Label Text Style, Text Position Styles for the text label on a field. Detail Text Style, Text Position Styles for the detail text label on a field. Text Text Style, Text Position Styles for the body text of a field.


Properties Styles are defined as a dictionary of properties.

Text Style Style Values Description font-size "<int>" Font size of the element. font-weight "<bold | normal>" Font weight. font-style "<italic | normal>" Font style. font-family "<serif | sans-serif>" Font family. color "rgb(<r>,<g>,<b>)" | "#FFFFFF" | "<common color name>" Text color.

Text Format Style Values Description text-align "<left | center | right>" Aligns the text. Must be set as field property. text-lines "<integer>" Number of text field lines to display.

iOS style considerations When developing Mobilizer client applications for iOS targets, consider the following style guidelines:

• When setting button styles, consult the Apple iOS Human Interface Guidelines. • Make sure that lists are updated if they are bound to data using KeyValueUpdate. • Set the background image on the choice menu because it does not use the default

background. • Make sure that the styles are set correctly to push a form during form-stack based login. • Padding:

Set the padding for each a field, not just at the form level. Form padding does not always work correctly when a text field precedes other fields such

as text, choice, and so on.


Implementing Mobilizer Chat This section describes how to implement Interaction Mobilizer Chat based on XMPP. For information about installing chat components, see the Interaction Mobilizer Installation and Configuration Guide. Chat impacts several components within Mobilizer:

• XMPP Server • Administrative Configuration • Mobilizer Scripting Language (MSL) • Front End Server • Client Applications • Mobilizer XMPP Bridge • CIC XMPP Bridge

Scripting Chat in MSL Similar to callbacks, you can use MSL to:

• Create a new chat. • Enumerate the current chats for the session. • Disconnect/delete a chat.

The chat API in MSL hangs off ext.chats. For example, ext.chats.Create("Marketing") creates a chat for the current user session to the Marketing workgroup. The available MSL methods are: ext.chats.Create("[queue name]") ext.chats.Create("[queue name]") do |p| { /* can set options on the chat here, see below */ } ext.chats.CreateForUser("[user queue name]") ext.chats.CreateForUser("[user queue name]") do |p| { /* see below for chat options available here */ } // The following properties are available to set on the example "p" variable above, similar to how the callback API works: string QueueName string QueueType string CustomInfo string UserView.Title string UserView.SubTitle string UserView.Detail hash Attributes // name/value pairs hash RoutingContexts // name/value pairs ext.chats.GetAll() // returns an array of objects that have an "Id" string property containing the unique ID of the chat ext.chats.GetById("[id]") ext.chats.Disconnect("[id]")


Example MSL For creating a chat: createdChat = ext.chats.Create("Marketing") do (p): p.CustomInfo = "http://www.inin.com" p.Attributes["foo"] = "bar" p.RoutingContexts["spam"] = "ham" p.UserView.Title = "Chatting" p.UserView.SubTitle = target p.UserView.Detail = "Hard coded chat subject" end

Example MSL Action for creating a chat: action 'create_chat': target = request['chat_target'] subject = request['chat_subject'] createdChat = ext.chats.Create(target) do (p): p.CustomInfo = "http://www.inin.com" p.Attributes["foo"] = "bar" p.RoutingContexts["spam"] = "ham" p.UserView.Title = "Chatting" p.UserView.SubTitle = target p.UserView.Detail = "Hard coded chat subject" end if createdChat.Id == null: request.Alert( "Chat", "Error creating the chat") else: request.PopForm(true) end end

Creating a Chat Session Creating a chat session begins with a ChatEvent. // This MSL example creates a chat on the Marketing workgroup queue, // sets additional properties on the chat object that is created, // and returns a chat object.


// This MSL example is a full action function example which // pulls the target and subject from specified fields on a // configuration form.

Setting Up the Front-End Server for Chat Client applications can retrieve a list of current chats and callbacks, get details for a particular interaction, complete an interaction (via updating it), or delete an interaction. Timestamps are UTC (Coordinated Universal Time) in RFC 3339 format, using the format string: "yyyy-MM-dd'T'HH:mm:ssZ"

For more information about RFC 3339, see http://tools.ietf.org/html/rfc3339.

Getting Interaction Details You can use the GET function to retrieve interaction details for the current session.

HTTP Request GET /interactions/{id}

HTTP Response with JSON Body Content-Type: application/json; charset=utf-8 { "id": "b5539186-9673-4dc8-8923-4d2d07213a36", "type":"chat", "target":"marketing", "roomId":"[email protected]", "roomPassword":"Popcorn", "server":"prefix.example.com", "state":"active" }

Updating Interaction Details You can use the PUT function to update current chat interactions.

HTTP Request PUT /interactions/{id}

http://tools.ietf.org/html/rfc3339


HTTP Response with JSON Body Content-Type: application/json; charset=utf-8 { "state":"completed" }

Getting All the Interactions You can use the GET function to retrieve all chat interactions for the current session.

HTTP Request GET /interactions

HTTP Response with JSON Body The response returns an array of interaction objects, including summary information needed for the interaction list form. Content-Type: application/json; charset=utf-8 [ { "$type":"ChatResponse", "type":"chat", "target":"marketing", "roomId":"[email protected]", "roomPassword":"Popcorn", "server":"sample.example.com", "id":"041X3E15-33A1-4X1E-8XXF-4C061X7A02D2", "state":"active" } ]

Deleting Interactions You can use the DELETE function to delete the current chat session interactions.

HTTP Request DELETE /interactions/{id}

HTTP Response 200 OK

Listing Current Chat Sessions In the Interactions GUI, the user can see all their active (and historical) chats, including which chats have updates and which chats they have not viewed. Selecting a chat brings the user into the GUI for that chat. Users can delete historical chats, using a process similar to deleting historical callbacks.

Built-in Chat GUI Code the built-in chat GUI to support the following functions:

• Entering text into the chat (chatting). • Viewing the participant names. • Disconnecting the chat session.


Connecting and Maintaining an XMPP Server Connection When possible, the client reuses the same chat/XMPP connection across all existing chat sessions. If a connection does not exist when the system receives a ChatEvent, the client creates a new chat/XMPP connection. If the Mobilizer user navigates away from the current chat window within the Mobilizer application, the system closes the XMPP connection. The Mobilizer server sends a push notification if the CIC agent sends another message to the Mobilizer user. The chat UI indicates that a message arrived via the platform’s native notification mechanism. Once the system acknowledges the user notification, it returns the user to the chat UI and the re-establishes the XMPP connection. The Mobilizer server automatically disconnects a chat session after the configured timeout period unless the user restarts the Mobilizer application. When a user starts a Mobilizer application, it queries the server for existing chats, reconnects the XMPP connections, and rejoins chat rooms as appropriate.

Mobilizer XMPP Bridge The Mobilizer XMPP Bridge is the XMPP server component responsible for managing chat rooms created via MSL requests, managing the current set of active chats in MongoDB, and responding to events in order to continue workflow. For example, when a client joins a chat, this bridge continues by inviting the CIC bridge to join. Primarily, this bridge is responsible for:

• Waiting for requests to start a chat or disconnect a chat. • Updating MongoDB to reflect the current state of chats. • Automatically configuring the XMPP server (if appropriate). • Creating chat rooms, including dynamically creating passwords. • Inviting CIC (via the CIC XMPP Bridge) to join a chat room. • Asynchronously sending notifications when new a non-Mobilizer participant such as CIC adds

text. • Cleaning up the chat room when participants leave and chatting ends; or during the chat, if

CIC leaves the room. • Proactively remove all participants from the chat and delete the chat room, if the chat is

intentionally disconnected.


CIC XMPP Bridge The CIC XMPP Bridge is another XMPP server component. It manages the connection between XMPP and CIC Interaction Web Tools (IWT). CIC XMPP Bridge includes one Mobilizer database query that looks up more chat information based on which chat room CIC was invited to join. This is required so that Mobilizer can include extra metadata such as custom attributes and routing contexts. When a chat request reaches the bridge, via XMPP, it accepts the request and marshals between IWT and XMPP. Chat requests include joining a chat room. XMPP represents each CIC participant as a separate participant, in addition to the CIC system which is represented in all chat rooms as the hard-coded user [email protected]. The CIC XMPP bridge polls IWT for chat updates and submits them to the XMPP chat server. If an XMPP chat request arrives for a chat that CIC no longer knows about (such as the chat is in the bridge's XMPP to CIC mapping, but CIC returns a not found error) then the bridge leaves that particular chat room. If the bridge receives a CIC chat update for a chat room that no longer exists, it disconnects the chat using the IWT APIs.

Push Notification Architecture In this design, the mobile devices first register with the appropriate push service based on their platform. iPhones register with Apple Push Notification Service (APNs) and Android phones register with Google Cloud Messaging (GCM). Once the devices receive their push ID from the provider, that ID is then registered with the Mobilizer session via the front end servers and stored in MongoDB in the sessions collection. To send a push notification to a device, all the push server needs is the session ID to receive the push notification. The metadata is stored in MongoDB with that session, so the push server can determine which platform push channel to use when sending notifications.


Publishing Mobilizer Client Applications To publish Interaction Mobilizer client applications, you need Microsoft Windows PowerShell 2.0 and the Interaction Mobilizer module. For more information about installing Interaction Mobilizer, see the Interaction Mobilizer Installation and Configuration Guide.

Installing the Interaction Mobilizer Command Line Interface Make sure that Microsoft Windows PowerShell 2.0 is installed:

1. Click Start > All Programs > Accessories > Windows PowerShell > Windows PowerShell.

2. Type $host.Version and press Enter to check the version number. Interaction Mobilizer requires Windows PowerShell 2.0.

3. Exit Windows PowerShell. If you are using Windows PowerShell on the Interaction Mobilizer server, run the executable file mobilizer_config.exe from the Share folder of the installation directory. For example: c:\Program Files (x86)\Interactive Intelligence\Mobilizer\Share\mobilizer_config.exe To use Windows PowerShell on a different computer, install the Interaction Mobilizer Windows PowerShell Module and run the mobilizer_config.exe file.

1. Create the following directory, including all parent directories if they do not exist: %USERPROFILE%\Documents\WindowsPowerShell\Modules\InteractionMobilizer

2. Copy all files from the Mobilizer Server share \\server\Mobilizer_Modules\InteractionMobilizer into the directory created in Step 1.

3. Run mobilizer_config.exe from the Share folder of the installation directory.

Interaction Mobilizer commands All commands in this section must be run from the Interaction Mobilizer command line interface:

mobilizer_config.exe

Create a new empty application directory structure To create an empty directory structure under the current directory, run the New-MobilizerApp command with no parameters. To create an empty directory structure in a new subdirectory called my_app, add a single string parameter using the syntax:

New-MobilizerApp my_app

Publish the existing application The Publish-MobilizerApp command publishes all configuration, actions, initializers, and certificates, using the current directory as the source application.

Notes:

This command fails if it encounters a script compilation error.

MongoDB parameters are case-sensitive. Use lowercase when possible to avoid confusion.

Run the Publish-MobilizerApp command with a single parameter which is the database connection string. The connection string must be formatted "mongodb://server1/database_name" For example, a complete command line that publishes the current application to a computer named server1 in the interact subdirectory:

Publish-MobilizerApp "mongodb://server1/interact"


Automatically republish the application if a file changes The Start-AutoPublish command monitors the application found in the current directory for any changed, added, or deleted *.msl file or *.css/.scss/.less file. A change automatically triggers republishing of the application. Press CTRL-C to stop the auto-publish process. The command syntax:

Start-AutoPublish "mongodb://server/database"

Tip:

Use this command to test and validate the application against a development server. Do not use this command to publish a final application to production.

Test the current application The Test-MobilizerApp command compiles the current Interaction Mobilizer application and displays any warning or error messages. This command does not publish the application. The command syntax:

Test-MobilizerApp

Get the configuration code Use this command to speed application startup by publishing the initial configuration to an app store or other destination. The Get-MobilizerFormConfiguration command compiles and runs the configuration MSL code and displays the JSON representation of the form definitions as a string. You can copy and paste the string, or pipe it to a file. The command syntax:

Get-MobilizerFormConfiguration


Integrating Applications with Interaction Mobilizer Design and implement connectivity into Mobilizer applications. Mobilizer client applications must communicate with the Mobilizer database, Mobilizer server, and integration service.

Integration Service Connections The customer is responsible for developing, hosting, and maintaining the integration service. It must be able communicate with Mobilizer front-end servers using HTTP via port 80 for non-SSL and port 443 for SSL.


Security Considerations Mobilizer includes state-of-the-art security measures including encryption and certificates to safeguard contact center customer information.

Data Encryption in Mobilizer In some cases, you must encrypt user-entered data. This section describes how to design the encryption and handle the data. Data encryption involves several things:

• Certificates (including a Certificate Authority) • Specifying what data must be encrypted (and with what certificate)

Certificates Interaction Mobilizer encrypts data using X.509 certificates. A trusted certificate authority must sign the certificates. Interaction Mobilizer renames each certificate to help you identify which one to use. Using certificates affects these components: the Mobilizer client application (iPhone, Android) and your organization’s integration service. To implement encrypted data in an Interaction Mobilizer deployment, a trusted root certificate from a valid Certificate Authority (CA) is required, and must be included in all client applications used. A valid CA can include anything from a third party such as VeriSign or Comodo, to a Domain CA, or a self-signed certificate. The only requirement is that all the client applications involved must trust the root certificate of the CA. The scope of a CA is outside the Mobilizer infrastructure. You must load Interaction Mobilizer with valid certificates.

Interaction Mobilizer Clients Provide Interaction Mobilizer client applications with a trusted root certificate at build/deploy time to verify all certificates and retrieve them from the server. Mobilizer client applications must load the current set of certificates from the front end server. Client applications must also encrypt any field the configuration specifies as encrypted, using the certificate specified in the configuration for the field.

Customer Integration Service The integration service (responding to HTTP requests from Mobilizer) must be able to access the private keys that correspond to the public keys used in the data encryption certificates. Management and use of these private keys is outside the scope of Mobilizer. Interactive Intelligence does not recommend storing private key information in flat files or using without a key store. The private key is a sensitive piece of information and must be protected. Interactive Intelligence recommends that the use of OS-specific key stores for managing private key data.

Specifying Encrypted Fields In the configuration MSL you can specify certain fields as encrypted, and name a certificate to use for encryption. Method: encrypted_with Parameter: string name of certificate The encrypted_with method marks a field as being encrypted using the specified certificate. If the certificate is not found, Mobilizer logs an error in the diagnostic database. The client application does not transmit any data to the server for this field. Additionally, any field marked as encrypted_with does not process key/value store data binding, nor is the value accessible from within the action MSL.

http://en.wikipedia.org/wiki/X.509


Scripting Tutorial Welcome to the Interaction Mobilizer scripting tutorial. This section describes the basic concepts and coding techniques you need to know before developing your own Mobilizer Scripting Language (MSL) applications. MSL is a simple scripting language. It is helpful to have some programming experience, but you do not need to have any experience with scripting languages.

MSL Background MSL is derived from the Boo script style programming language. Boo is a .NET language, so it has the same capabilities of other .NET languages. MSL is a subset of Boo. If you decide to use advanced features of Boo and are unsure of the syntax, there are several websites dedicated to learning Boo. This document does not describe basic Boo constructs because you do not need to know them to use MSL.

Getting Started 1. On your desktop, locate the file hello_mobilizer.apk.

2. Install the file on a network-enabled Android device. When you run the application the first time, it prompts you to enter the IP address. Enter the IP address of your virtual machine.

3. From the Android device, run the application to display the following screen:

4. Tap Let’s begin to display the list of tutorials. Each tutorial can be completed individually, but you should complete them in order.


Editing Source Code Mobilizer includes a text editor called Sublime Text 2. Use this editor, or any plain text editor, to code MSL.

1. From your desktop, locate the source code folder hello_mobilizer.

2. The hello_mobilizer folder includes two folders: app and certs.

3. Open the app folder. This folder contains four folders: Actions, Config, Initializers, and Styles. Most of your work is completed in the Config folder. • Config – This folder contains the code for the forms used in the tutorial and Mobilizer

applications in general. Every screen displayed in the application is stored here. • Actions – This folder contains the code that runs on the server. Server action code

includes database queries and other processing that must be done outside the application. • Styles – All controls that appear on forms and the forms themselves must have styles

associated with them. Styles work much like CSS and share syntax. Use styles to make your application meet your look and feel standards.

• Initializers – Some applications need data to drive menus and lists at startup. Use this folder to store data needed when the application starts.

Compiling and Publishing 1. From your desktop, find the file mobilizer_config.exe. Use this tool to publish your

application to the local server. Once published, you can view your application on an Android device.

2. Open a command window and change directories: cd hello_mobilizer

3. From this folder, each time you change something and want to publish a new version, run the following command: Publish-MobilizerApp mongodb://localhost/hello_mobilizer


Tutorial: Working With Text 1. From the application, tap the Working with text tutorial to display the following screen:

2. On the desktop, open hello_mobilizer/app/Config/working_with_text.msl in a text editor. The code looks like: form 'working_with_text' title 'Text' info '', 'This tutorial is labeled "Working with Text" and can be found in tutorial.pdf on your desktop.' // Add your code here info '','' info '','' grid 'seeMyChanges', 1 action_entry 'myChangesEntry', 'see_changes' label '' image_uri 'im_done.png'

3. Under the //Add your code here line, add the following text: info 'myInfo', 'This is my first line of code'

This line of code has three parts. The first part of a line of the line describes the type of field. In this case, it is an info field. An info field is a simple label that displays text. Users cannot interact with an info field, it is for display purposes only. The second part of the line defines


the name of the parameter for the info field, in this case MyInfo. The last part of the line is the actual text to display on the form.

Note: On this form, there are other types of fields. The name of each field starts the line. The field names are form, info, grid, and action_entry.

4. Compile and publish your code. From the mobilizer_config.exe window type: Publish-MobilizierApp mongodb://localhost/hello_mobilizer

Make sure that your application published. Any error messages appear in red. If you receive an error message, fix the code and try again.


5. From the Android application, tap See my changes. Navigate back to view the result:

This example displayed static text in the application. Experiment by entering different text in the info field. To insert a new line, enter \n where you want the line to break. Try it and notice the difference between using \n compared to using one info field right after another.

Notice that the text is the default size, color, and alignment. Continue to the next tutorial and to learn how to customize the output of an info field through styling.


Tutorial: Styling Text After creating your first info field, you may have some questions about how to change the style of the text. This tutorial describes how to change the font size, color, and alignment. Styling objects in Mobilizer is similar to CSS styling for webpages.

1. In a text editor, open hello_mobilizer/app/Styles/hello_mobilizer.css.

In this file there are several styles already created for Mobilizer applications. The form style sets the background image for all of our forms. Other styles in this file change the font, the element size, color, and so on.

You can apply styles generically to all fields or forms, or apply styles specifically to individual items.

2. From the application, tap Styling Text to display the following screen:

The next steps describe changing the style of This is example text in the info field.

3. In the hello_mobilizer.css file, find the style created for this tutorial. Edit the style code to change the appearance of the info field. It looks like: info.example { }


4. Edit the file and add the following style information: info.example { font-size: 18; color: Yellow; text-align: center; }

5. Save the file.

If this line was only labeled info, this style would apply to all info objects.

To apply the style to a specific field, it needs a unique name added to the label, in this case the name is example.

The properties within the brackets are:

font-size – sets the size of the font in points. color – determines the foreground color in RRGGBB, r, g, b formats and basic color names.

Note that opacity must be specified separately. text-align – specifies how the text is justified: left, right, or center.

If you are using a code editor such as Sublime Text, as you begin typing a property name the editor suggests property names. Mobilizer supports most, but not all CSS style properties.

Once you have created a style, you need to apply it to the info field of the tutorial form.

6. Use a text editor to open hello_mobilizer/app/Config/styling_text.msl.

7. Find the reference to the info field: info 'myExampleText', 'This is example text' field_class 'example'

Styling is applied by using the keyword field_class followed by the name of the style. In this case we named the style example.

8. Publish your application. After publishing, go to the application and tap See My Changes.


9. Make sure your changes display correctly, then navigate back to the Styling Text tutorial.


Tutorial: Adding Forms Previous tutorials covered adding fields and setting styles. To add features to your application, you need the ability to make multiple forms.

1. In the application, navigate to the Adding Forms tutorial.

2. Tap the arrow. The application displays a blank form. In its current state, the code behind the form does not specify what happens when you tap the arrow.

3. From the desktop, open hello_mobilizer/app/Config/adding_forms.msl.

4. Find the first grid object. grid 'formTransitionGrid', 1 field_class 'nextGrid' form_entry 'nextArrowEntry', ' ' label '' image_uri 'next.png'

To understand how grid works, you need to know:

• The first item is the field grid. A grid creates a layout of images like tiles. The tiles are evenly spaced across the screen. In this case we only need one tile, so 1 is the second argument on the grid line. The first argument, like all fields, is the name of the field.

• The second line is mentioned in the preceding Styling tutorial. The field_class applies styling to the grid. Here we are specifying how big we want the grid to be.

• The third line down, form_entry, the subject this tutorial. The form_entry line tells the application that you are creating a grid entry that navigates to another form. The first argument of form_entry is the name, in this case nextArrowEntry. The next argument is intentionally left blank, and specifies the target form.


• The fourth line down is label. This line specifies the label text. The label entry has been left blank.

• The last item is the image_uri. Use this field to add a path (if needed) and file name for the image. The image next.png is packaged into the .apk file.

5. Change the second argument of form_entry set the target form name. Enter the text example_form between the empty quote marks. form_entry 'nextArrowEntry', ' example_form'

6. From the desktop, open hello_mobilizer/app/Config/example_form.msl. Notice that the name of the form on the first line is example_form. The name matches the second argument of form_entry, the navigation target.

7. Save and publish your changes.

8. In the application, navigate back to the Adding Forms tutorial and tap the arrow.

The application displays the Example screen:


Tutorial: Using Actions The previous tutorials involved changes to the application on your device. To build a useful application you need to be able to communicate with a server. Applications need the ability to send and receive data to and from a server. This tutorial describes common ways to use Actions to make our applications useful.

1. On your device, navigate to the tutorials and tap Using Actions.

2. Tap the gear symbol. The screen displays the text Loading for a moment. This happens because the form specifies an action, but does not indicate which action.

3. From the desktop, open the file hello_mobilizer/app/Config/using_actions.msl. The last item in this file is a grid similar to the one used in the previous tutorial. grid 'actionGrid', 1 field_class 'nextGrid' action_entry 'actionEntry', '' label '' image_uri 'gear.png'

Notice that this grid is slightly different from the one in the previous tutorial. Instead of specifying a form_entry, we specify an action_entry. The action_entry tells the application to execute the specified action.

4. Edit the file as follows to add the name of our new action and then do something interesting with it. action_entry 'actionEntry', 'myFirstAction'


5. Save the file.

The new value links action_entry to myFirstAction, which is triggered by tapping the gear.

The next step is to make something happen when myFirstAction runs.

6. From the desktop, open hello_mobilizer/app/Action/actions.msl.

This file includes some default actions that enable the application to navigate based on user choices. Any code that you write in action files is executed on the server, not the device.

You can perform sophisticated operations here. This tutorial describes a relatively simple action.

7. Create an action called myFirstAction. The name of the action must match the one used as the second argument of action_entry. action 'myFirstAction': add1 = 1 add2 = 2 sum = add1 + add2 request.Alert("Sum", "The total is: " + sum) end

8. Save the file and publish the application.

9. Open the application on your device and tap See My Changes.

10. Tap the gear to display the following:

This action asked the server to add one plus two (1 + 2) and display the result.

You can use Actions to perform many sophisticated operations, such as submit data from a user-completed form, create callbacks, and call external web services. These operations are outside the scope of this tutorial.


Navigating with Forms There are two basic navigation operations you need to know before completing this tutorial: request.popForm and request.popForm. First, change the request.popForm value to navigate back one form or to the home screen.

1. From the desktop, open hello_mobilizer/app/Action/actions.msl.

2. Delete the four lines of code below your action and enter the following text: request.PopForm(false)

3. Save the file and publish your application.


5. Tap the gear icon. The application navigates one form back from the current screen.

If you change false to true, tapping the gear navigate all the way back to the beginning of the application, which in this case is the same as tapping See My Changes.

Second, you can change the request.popForm property to push forms to the application based on user input.

1. For the last exercise, open hello_mobilizer/app/Action/actions.msl.

2. Delete the request.popForm line of code and enter the following text: request.PushForm(‘example_form’)

3. Save the file and publish your application.


5. Tap the gear icon.

The application should behave the same as form_entry did in the previous tutorial. This behavior is useful because it allows you to push forms based on user action or execute code on the server and then accept navigation.

Conclusion After completing this tutorial you should be able to write basic Mobilizer applications using MSL. For more information about other fields that you can use in applications, see Developing Interaction Mobilizer Applications and Appendix A: Mobilizer Configuration API.


Appendixes In this section: • Appendix A: Mobilizer Configuration API • Appendix B: Reporting and Data Tracking


Appendix A: Mobilizer Configuration API This appendix lists Application Programming Interface (API) functions that are specialized or unique to Interaction Mobilizer configuration.

• action • action_entry • button • choice • display_default, display_subtitle, display_value1, display_value2 -> list • encrypted_with • facebook_entry • field_class • field_property • form • form_class • form_entry • form_property • grid • image_uri • info • initialize • input_url, input_email, input_number, input_decimal, input_phone • label • lines • link • list • login • max_length • menu • min_length • password • placeholder • pressed_image_uri • regular_expression • required • required_role • row_id, row_text, row_detail_text, row_image_uri • style • text • title • toggle • url • url_entry


action Defines an operation that can be called from an action_entry. Use this element to perform advanced operations using special .NET, Web, or other methods.

syntax action actionName as string [msl code] end example action 'viewContactDetails':

selected = request[request.FieldId]

If selected == 'johndoe':

request.PushForm('johnDoeForm')

elif selected == 'janesmith'

request.PushForm('janeSmithForm')

end

end

action_entry Applies to: field Use this action entry to find and call actionName to perform advanced code execution from a control field.

syntax action_entry id as string, actionName as string example button 'submit'

label 'Submit'

action_entry 'submitting', 'submitAction'

button Use this control field to display a default button that enables interaction with the Mobilizer application using an action_entry call.

syntax button id as string example button 'submit'

label 'Submit'

action_entry 'submitting', 'submitAction'


graphics

Android iOS

choice Use this field to present the contact center customer with a list of selectable options. You can build a list of choices using one of three methods, according to the following syntax:

1. Use the choicesKey to dynamically build the choice list as a list of strings formatted as [ 'a1', 'a2' ].

2. Use a list of hash values formatted as [ { '1' : 'a' }, { '2' : 'b' } ].

3. Use explicit static definitions of the choice list using the same types described above, a list of strings, or a list of hash values.

syntax choice id as string, value as string, choicesKey as string choice id as string, value as string, choices as List of Hash choice id as string, value as string, choices as List of String graphics

Android iOS


display_default, display_subtitle, display_value1, display_value2 Applies to: list Use this attribute to set the display type for the list.

syntax display_default example list 'list_${name}', 'toy_products'

display_default

row_id '#{id}'

row_text '#{id}'

row_detail_text '#{desc}'

row_image_uri '#{toy_img_uri}#{id}.png'

graphics

Android iOS


encrypted_with Applies to: text field Use this attribute to encrypt a text field with a certificate.

syntax encrypted_with certname as string example text 'password'

required

password

encrypted_with 'auth_cert'

facebook_entry Applies to: control field Use this action entry to start a Facebook login and then run the action with the result of the Facebook login.

syntax facebook_entry id as string, action as string example button 'submit'

label 'Submit'

facebook_entry 'fblogin', 'FBLoginAction'

field_class Applies to: field Use this attribute to set a style class that is defined in the CSS style file.

syntax field_class classname as string example some_form.msl: info 'contact_info', 'Contact Info'

field_class 'personText' style.css: info.personText { font-size:14; font-weight:bold;text-align:center; }


field_property Applies to: field Use this property to enable entry of metadata on the field used by the Action MSL, via field.Properties('key').

syntax field_property key as string, value as string

example form 'some_form' text 'some_text' field_property 'custom_validation', 'some_value'

form

Use this field to define a form, which represents a page that can contain control fields. All navigation in Mobilizer applications occurs between forms.

syntax form id as string

example The following code creates a form: form 'your_formName' title 'My Title'

form_class Applies to: form Use this attribute to assign a style class to a form, which will apply to all elements in that form.

syntax form_class classname as string

example main_form.msl: form 'main_form' form_class 'padding20' styles.css: form.padding20 { padding:20 }


form_entry Applies to: control field Use this action entry to call the form specified by formid when using the associated control field.

syntax form_entry id as string, formid as string example button 'submit'

label 'Submit'

form_entry 'mainPage', 'PostLoginForm'

form_property Applies to: form Use this property to enable entry of metadata for the form used by the Action MSL, via form.Properties('key').

syntax form_property key as string, value as string

example form 'some_form' form_property 'some_name', 'some_value'

grid Use this field control to position subelements in columns according to the number specified. If you do not specify a value, the default is three columns.

syntax grid id as string, [optional] columns as integer example grid 'firstGrid'

button 'one'

button 'two'

button 'three'

or grid 'secondGrid', 2

button 'one'

button 'two'


graphics

Android iOS

image_uri Applies to: field Use this attribute to specify the directory location of an image to display for a field. URIs without a fully qualified path default to the client’s image directory.

syntax image_uri uri as string example info 'contact_info', 'desc' image_uri 'phil_koch.jpg'

graphics

Android iOS


info Use this field to display optional default text. Unlike the text field property, text set using info cannot be edited by the contact center customer.

syntax info id as string, [optional] value as string example info 'contact_info', 'This is the contact info:'

graphics

Android iOS

initialize Use this property to run specified code when the mobile application starts on a remote device. The initialize function is useful for setting default variables and global cache information.

syntax initialize: [variables to initialize] end example initialize: global['addedNotes'] = ['desc'] end


input_url, input_email, input_number, input_decimal, input_phone Applies to: text Use this attribute to restrict the format of text that the contact center customer can enter in a text field.

syntax input_url example text 'inputText', ''

input_email

graphics

Android iOS


label Applies to: field Use this attribute to associate a label with a field. If defined, the label appears over the specified control displaying the specified text.

syntax label text as string example button 'submitButton'

label 'Submit'


graphics

Android iOS

lines Applies to: text field Use this attribute to define the minimum and maximum number of lines in a text field to display as the text box.

syntax lines minlines as integer, maxlines as integer example text 'inputBox', ''

lines 2, 4

graphics

Android iOS

link Use this property to display an active link to standard website, email address (using mailto:), or telephone number (using tel:). When the contact center customer clicks or taps, the application processes the link using the device’s default application.

syntax link id as string, link as string, display as string example link 'Goog', 'http://google.com', 'Google'

graphics

Android iOS


list Use this control field to store a list of values. Add the row_* and display_* subelements to format a list with dynamic and static data.

syntax text id as string, sourceKey as string

example list 'contactsList', 'myContacts'

row_text '#{contactName}'

row_detail_text '#{contactInfo}'

row_image_uri '#{contactImage}'

display_subtitle

row_id '#{contactId}'

action 'viewContactDetails'

Elsewhere in the MSL code: client['myContacts'] = [{'contactName':'John Doe', 'contactInfo':'Supervisor', 'contactImage':'johnDoe.png', 'contactId':'johndoe'},

{'contactName':'Jane Smith', 'contactInfo':'CEO', 'contactImage':'janeSmith.png', 'contactId':'janesmith'}] In the actions: action 'viewContactDetails':

selected = request[request.FieldId]

If selected == 'johndoe':

request.PushForm('johnDoeForm')

elif selected == 'janesmith'

request.PushForm('janeSmithForm')

end

end

graphics

Android iOS


login Applies to: form Use this attribute to specify the name of the Mobilizer client application login form to display when the user starts a login. Use only one form as the login form.

Syntax login

example form 'login_form' login

graphics

Android iOS


max_length Applies to: text field Use this attribute to set a maximum text field length.

syntax max_length length as ushort example text 'inputText', ''

max_length 25

graphics

Android iOS

menu Use this field container to define a menu to display on a client application. This field is similar to a grid in that it keeps subelements together as a menu (text only).

syntax menu id as string example menu 'selectionMenu'

graphics

Android iOS


min_length Applies to: text field This attribute defines a minimum text field length.

syntax min_length length as ushort example text 'inputText', ''

min_length 5

graphics

Android iOS

password Applies to: text field This attribute hides text as it is typed, behavior needed for fields receiving sensitive information such as a password field.

syntax password example text 'passwordField', ''

password

graphics

Android iOS


placeholder Applies to: text field This attribute defines text that appears in a field before the contact center customer enters information.

syntax placeholder text as string example text 'userTextField', ''

placeholder 'Type your input here. '

graphics

Android iOS

pressed_image_uri Applies to: grid Use this attribute to display an image in the grid of the client application, indicating where to click or tap within the grid.

syntax pressed_image_uri uri as string example grid 'stuff', 2

button 'one'

pressed_image_uri 'button_one_pressed.png'

button 'two'

regular_expression Applies to: text field Use this attribute to define a regular expression restricting what type of characters can be displayed in a text field.

syntax regular_expression pattern as string, message as string example text 'regex'

label 'RegEx=[0-9a-fA-F]*'

regular_expression '[0-9a-fA-F]*', 'Only alphanumeric characters are allowed.'


graphics

Android iOS

required Applies to: text field This attribute defines an input field as a required field. The client application cannot process any actions (*_entry or otherwise) until the contact center customer completes all required input fields.

syntax required example text 'inputField', ''

required

required_role Applies to: form Use this attribute to specify which category of contact center customer can see the form once they are logged on to the application.

syntax required_role rolename as string example form 'user_page'

required_role 'authenticated'

graphics

Android iOS


row_id, row_text, row_detail_text, row_image_uri Applies to: list This attribute defines individual row information for lists.

syntax row_id id as string row_text text as string row_detail_text text as string row_image_uri uri as string example list 'incidentId', 'Incidents'

row_text '#{incidentId} #{state}: #{status}'

row_detail_text '#{updateDateTime} #{description}'

row_image_uri '#{imageUri}'

row_id '#{incidentId}'

graphics

Android iOS

style

Use the style property to define a CSS element that you can apply to a form or control field. You can use style to set the control’s alignment, font style, padding, color, and so on. Mobilizer supports a subset of the CSS formatting elements, for more information see Setting Styles.

Syntax style selector as string, styles as hash

Code The following code creates a new style that applies to an info field: //css file info.titleText { font-size:18; font-weight:bold; text-align:center; } //msl file info 'infoName', 'your info text' field_class 'titleText'


graphics

Android iOS

text Use a text field to define a field that accepts contact center customer text input. You can optionally display default text in the field. To create a field that does not accept contact center customer input, see the info element.

syntax text id as string, [optional] value as string example text 'textFieldID'

or text 'textFieldID', 'Optional text'

graphics

Android iOS


title Applies to: form Use this attribute to define the form title that appears in the client application default header space, above the form.

syntax title text as string example form 'mainForm'

title 'Main Form'

graphics

Android iOS

toggle Use this element to display an on/off toggle switch.

syntax toggle id as string, [optional] value as string example toggle 'toggle', 'On?'

graphics

Android iOS

url Applies to: field Use this attribute to define a URL link for a control field like a button or menu item. This attribute is similar to link, which applies a URL to text.

syntax url url as string


graphics

Android iOS

url_entry Applies to: control field Use this entry action to display the specified URL in a Web view within the client application.

syntax url_entry id as string, url as string example grid 'bookmarks', 1

url_entry 'bookmark1', 'http://www.google.com'

url_entry 'bookmark2', 'http://www.facebook.com'


Appendix B: Reporting and Data Tracking Interaction Mobilizer requires two data storage components to process reporting data: the reporting data and raw statistics data. Mobilizer client applications generate raw statistics data during contact center customer interactions. Mobilizer stores the raw statistics data in a Mongo database collection named Statistics. To speed report generation, Mobilizer compiles reporting data and stores it in an SQL database.

Raw Data Raw data is a list of events tagged with the application session ID. You can use the session ID to associate events with a single user endpoint or session. Mobilizer also time-stamps events to help you build a timeline or event chain per user. You can further describe events by associating any number of information fields with an event. Mobilizer logs events as raw data from the client application. Explicit event logging methods record basic Mobilizer functions, and an MSL interface enables you to add customized statistics events.

Raw Data Interfaces The IStats interface makes available methods to log statistics as raw data. You can also develop an MSL interface to log custom events.

Raw Data Structure Mobilizer stores the raw data in the Statistics MongoDB collection. Set up the Statistics database using the MongoDbStatisticsConnectionString configuration file attribute, which is separate from database for the key-value store and other collections for use by client applications. Set up the non-statistics Mongo database using the MongoDbConnectionString configuration file attribute. Each document in the Statistics collection represents a single logged statistics event.

Note:

MongoDB parameters are case-sensitive.

Field Name Field Type Description

sid String The session ID (sid) is a string identifying the client-generated identifier that define a single user of the client application.

ts Date The time stamp (ts) is the Coordinated Universal Time (UTC) date and time of the event. Use the yyyy-mm-ddThh:mi:ss.fffZ format. Always use three digits in the fractional seconds portion, setting the granularity of the timestamp to one millisecond (ms). The time stamp is the only indexed field in the Statistics collection.

tso Integer The time offset (tso), in minutes, of the front-end server local time from UTC. Adding the time offset to the time stamp determines the local time.

eid Integer The event ID (eid) is a number describing the type of event. The event ID and name of the event are cross-referenced in the statEvents collection. For more information, see the Events and Event-specific Data table.

* * You can define event-specific data using any unique field name. You can define any number of event-specific data fields and values. Use the event ID to set the required and optional fields.


Use the StatisticsEvents collection to store descriptive information about events:

Field Name Field Type Description eid Integer The event ID (eid) is a number describing the type of event.

en String Define the name of the event and use this name to call the MSL interface to add an event to the access token's event list.

ef Array of Objects

Defines the fields allowed per event. The event fields are an array of objects, in which each object defines one allowed field per event. Each object contains two fields:

name – A String value containing the name of the event-specific data field. required – A Boolean value that is true if the field is required, and false if the

field is optional. Use eventFields to validate input for custom events.

Events and Event-specific Data These data are the standard events and the related event-specific data for the standard, pre-defined events. Customer-defined events have event ids starting at 100001. Customer-defined events can be set up in the MSL scripts.

EID eventName Field Name Required Description

1 config appname true The name of the client application. This value is the Mobilizer client application name, not the branding name.

appver true The version of the client application. As with appname, it refers to the Mobilizer client application name, not the branding name.

platformname true The name of the client application’s target platform. platformos true The platform operating system name and version.

brandname true The branded configuration name for use in forms. Use the branded configuration name to determine which forms the contact center customer accessed.

brandver true The branded configuration version for use in forms. Use the branded configuration version to identify which version of a set of forms the contact center customer accessed.

failreason The reason a configuration fetch request failed. The returned value is null when successful.

2 action actionname true The name of the action taken, which is the same as the name used in the action request.

formid true The ID of the form from which a contact center customer started an action.

fieldid true The ID of the field associated with the actionname. 3 pushform target true The target form ID. formid true The form ID that is pushed to the navigation stack. 4 modalform target true The target form ID. formid true The form ID of the modal form.


EID eventName Field Name Required Description 5 popform target true The target form ID. all true One of true or false. 6 fieldinvalid target true The target ID of a form with an invalid field. fieldid true The ID of the field that is invalid. msg true A message describing why the field is invalid.

7 fieldvisible target true The target ID of a form containing a field that needs a visibility change.

fieldid true The ID of the field that needs a visibility change. visibility true One of visible, hidden, disabled, or gone. 200 webhook url true The URL of the webhook receiving a POST action. duration true The round-trip request/response time in milliseconds. rc true The HTTP response code for the request.

201 webhookauth authority true The name of the authenticating authority. Possible values include: facebook, twitter, isupport.

username true The user name used to authenticate under. url true The URL that the auth request is POSTed to. duration true The round-trip request/response time in milliseconds rc true The HTTP response code for the request

300 licenseacquire The client application acquired a license for this session, and does not log any other data.

301 licenserelease The client application released the license for this session, and does not log any other data.

302 licenseexcursion Any client application request is refused because the grace period has expired. Responding to the request would result in an active session, causing the number of currently active sessions to exceed the licensed amount.

350 licenseusage This event does not have an associated session ID, because it is logged periodically by the Mobilizer server.

intervalstart true The start date/time (in UTC) recording when the session check period began.

intervalstartoffset true The offset (in minutes) of the Mobilizer server's physical machine from UTC for the period start.

intervalstop true The stop date/time (in UTC) recording when the session check period ended.

intervalstopoffset true The offset (in minutes) of the Mobilizer server's physical machine from UTC for the period stop.

activesessions true The number of unique, active sessions counted for the period.

licensedsessions true The number of licensed concurrent sessions.


EID eventName Field Name Required Description

gracestate true The status of the grace period:

0 – Grace period unused. 1 – Grace period in effect. 2 – Grace period ended.

1000 callbackcreate targetqueue true The target queue name for a callback interaction.

targettype true The target type. Callbacks go to ACD routed workgroups, so this value must be Workgroup.

subject true The callback subject.

participantname true The name of the contact center customer receiving the callback.

participantphone true The phone number of the contact center customer.

participantid false The contact center customer’s participant ID returned by a successful callback. Not present if callback creation failed.

callbackid false The callback ID returned by a successful callback. Not present if callback creation failed.

failreason false The callback creation failure reason. Not present if the callback is successfully created.

1001 callbackreconnect callbackid true The callback ID to use when reconnecting a contact center customer.

participanname true The contact center customer’s name.

participantid false The contact center customer’s participant ID, returned in response to a successful callback reconnection. Not present if the callback failed to reconnect.

failreason false The reason a callback failed to reconnect. Not present if the callback successfully reconnected.

1002 callbackdisconnect participantid true The ID of the contact center customer to disconnect.

failreason false The reason a callback disconnect failed. Not present if the callback successfully disconnected.

1003 callbackmodify participantid true The ID of the contact center customer to modify. subject true The callback subject.

participantphone true The contact center customer phone number to use for a callback.

failreason false The reason a callback modify failed. Not present if a callback is successfully modified.


Client changes When programming a Mobilizer client application to make a configuration request, set the HTTP header string ININ-NGS-Client-Info in the form <app name>/<app version>/<platform hardware>/<platform OS>. The <app name> must be the name of the Mobilizer client application. The <app version> must be the version of the Mobilizer client application. The <platform hardware> must identify the mobile device running the Mobilizer client application. The <platform OS> must identify the operating system of the machine hosting the Mobilizer client application. The supported <platform OS> values for the <platform hardware> client information strings are:

• Mobilizer/1.0.0/iPhone/iOS 4.0 • Mobilizer/1.0.1/Android/Android 4.0.1 • Mobilizer/1.0.0/Samsung Galaxy/Android 4.0.2

Reporting Data The Mobilizer database, MongoBD, regularly moves raw data from the Statistics collection into a set of SQL tables. This process improves performance for report generation. Multidimensional queries for a range of reports can perform poorly when run on document-based databases. Running report queries on a set of SQL tables provides faster report generation.

Reporting Data Structure The reporting data consists of the following tables:

IMZ_RawEvents The IMZ_RawEvents table contains logging events from the MongoDB statistics collection.

Column Name Column Type Description

EventId UUID Primary key:

SQL Server – UNIQUEIDENTIFER Oracle – RAW(16)

EventTypeId Integer The event type ID describes the event. The EventTypeId is the same number as the EID stored in the Statistics MongoDB collection, and has a covering index.

SessionId String The session ID of the client that generated the events. The session ID connects events with the EventDate to provide a coherent usage timeline for a device.

EventDate DateTime The UTC date/time when the event occurred, in increments as small as one millisecond (ms).

EventDateOffset Integer The front-end server local time offset from the UTC in minutes. Add this offset to the EventDate to express the EventDate in the front-end server’s local time.


IMZ_RawEventData The IMZ_RawEventData table contains the key/value data pairs for the logging events pulled directly from the MongoDB statistics collection.




Name VARCHAR(255) Event data name. Value VARCHAR(1000) Event data value.

IMZ_ClientName The IMZ_ClientName table contains the client name. Use this table to track the client name.

Column Name Column Type Description ClientNameId INTEGER Primary key, auto-incrementing. ClientName VARCHAR(1000) Client name.

IMZ_ClientVersion The IMZ_ClientVersion table contains the client type and version. Use this number to set the client version, such as 1.0.1.0.

Column Name Column Type Description ClientVersionId INTEGER Primary key, auto-incrementing. ClientVersion VARCHAR(1000) Client version

IMZ_ClientPlatform The IMZ_ClientPlatform table contains the client platform name. Use this table to track client platform such as iPad, iPod, iPhone, Samsung Galaxy, and so on.

Column Name Column Type Description ClientPlatformId INTEGER Primary key, auto-incrementing. ClientPlatform VARCHAR(1000) Client platform name

IMZ_ClientPlatformOS The IMZ_ClientPlatformOS table contains the client operating system (OS) name and version. For example: iOS 4.1, and Android 4.0.1.

Column Name Column Type Description ClientPlatformOSId INTEGER Primary key, auto-incrementing. ClientPlatformOS VARCHAR(1000) Client platform operating system (OS) name and version.


IMZ_BrandName The IMZ_BrandName table contains the name of the customized set of MSL scripts and configuration files.

Column Name Column Type Description BrandNameId INTEGER Primary key, auto-incrementing. BrandName VARCHAR(1000) MSL script and configuration set name.

IMZ_BrandVersion The IMZ_BrandVersion table contains the version of the customized set of MSL scripts and configuration files.

Column Name Column Type Description BrandVersionId INTEGER Primary key, autoincrementing. BrandVersion VARCHAR(1000) Version

IMZ_EventType The IMZ_EventType table associate the name of an event with the event type ID. The EventTypeId is the same number as the event ID (EID) stored in the MongoDB Statistics collection. Use this table when generating reports to display the descriptive event type name rather than the event type ID.

Column Name Column Type Description EventTypeId Integer Primary key, auto-incrementing EventTypeName String Name of the event type

IMZ_EventDataNames The IMZ_EventDataNames table associates the name of an event data with the event data name ID. Use this table when generating reports to display the descriptive event data name rather than the event data name ID.

Column Name Column Type Description EventDataNameId Integer Primary key, auto-incrementing EventDataName String Name of the event type


IMZ_Events The IMZ_Events table store all reporting events. This table is the primary reporting table.




EventTypeId Integer The event type ID describes the event. This is the same number as the EID stored in the MongoDB Statistics collection, and has a covering index.

SessionId String The session ID of the client that generated the events. The session ID connects events with the EventDate to provide a coherent usage timeline for a device.

EventDate DateTime The UTC date/time when the event occurred, in increments as small as one millisecond (ms).

EventDateOffset Integer The front-end server local time offset from the UTC in minutes. Add this offset to the EventDate to express the EventDate in the front-end server’s local time.

ClientNameId Integer ID of the client name value. Has a covering index. ClientVersionId Integer ID of the client version value. Has a covering index. ClientPlatformId Integer ID of the client platform value. Has a covering index. ClientPlatformOsId Integer ID of the client platform OS value. Has a covering index. BrandNameId Integer ID of the brand name value. Has a covering index. BrandVersionId Integer ID of the brand version value. Has a covering index.

FormId String The form ID from the form that started the event. This value can be NULL if the event was not started from a form.

FieldId String The field ID from the field that started the event. This value can be NULL if the event was not started from a field.

IMZ_EventData The IMZ_EventData table stores event-specific data for statistics events. Some of the data in the raw statistics event documents have columns in the IMZ_Event table, but most do not. Use this table for data without columns in the IMZ_Event table. Use this table to associate an EventID with a Value. For example, an event with the EventTypeId (EID) 100 (authenticate) has three rows in this table: one for the authority value, one for the username value, and one for the failurereason value.


EventDataNameId Integer Key of event data name. Indexed but not as a primary key.

EventId UUID Key of event that the event-specific data belongs to. Indexed, but not as a primary key.

Value String Value of the event-specific data.


IMZ_SessionUsage The IMZ_SessionUsage table stores the active session usage data received from the Mobilizer server. This table tracks the number of active sessions for the configured check interval, the number of concurrently licensed active sessions, and the status of the grace period (not triggered, triggered but not expired, or expired). This table consists of one row per reported interval.


SessionUsageId UUID Primary key.

IntervalStart DateTime The UTC date/time when the interval started, in increments as small as one millisecond (ms).

IntervalStartOffset Integer The Mobilizer server's local time offset in minutes from UTC. Add this to the IntervalStart to express the IntervalStart in Mobilizer server local time.

IntervalStop DateTime The UTC date/time when the interval ended, in increments as small as one millisecond (ms).

IntervalStopOffset Integer The Mobilizer server's local time offset in minutes from UTC. Add this to the IntervalStop to express the IntervalStop in Mobilizer server local time.

ActiveSessions Integer The number of active sessions for the interval. LicensedSessions Integer The number of licensed sessions for the interval.

GraceStatus Integer Status of the grace period:

0 – Grace period unused. 1 – Grace period in effect. 2 – Grace period ended.

Compiling Raw Data into Reporting Data The Interaction Mobilizer integration service periodically transfers data from the MongoDB Statistics database. This process is divided into the following tasks:

1. Extracts a date-range limited set of statistics raw data documents from the MongoDB Statistics database and collection.

2. Splits the documents up into individual fields and inserts the data into a temporary holding table.

3. Once the documents have been committed into the temporary holding table, the raw statistics data is removed from the MongoDB Statistics collection.

4. Invokes a stored procedure to copy and reformat the data into the final Mobilizer tables.