Logical View of Kony Objects Services

Mobile applications typically perform operations on objects, such as getting a work order, updating it, and saving the work order. Object Services exposes the back end data using mobile friendly object APIs, including their rich metadata, so a developer can build client applications easily in a generic way that uses higher level constructs.

Object Services offers the following advantages for quickly mobilizing existing data and processes within LOB systems:

By using Object Services, a developer can define APIs for object access, object metadata access, object relationships, and binary data (for example, images and attachments). The following is the fundamental process for mobile app development with Object Services:

  1. Connect to a back end by using the connectors and data adapters available in Kony Fabric.
  2. Browse and import back end entities using metadata discovery.
  3. Transform the back end input and output by using a mapper and transformation layer.
  4. Expose OData style APIs for CRUD, querying objects for mobile app consumption.
  5. Add additional custom APIs that invoke various other back end APIs or run custom logic.

Object Services Architecture

The key concepts of Object Services are the app model, the mapper, and the data adapter.

App Model

Mapper

Data adapter

Objects Services has three primary components. The user-facing component is the REST APIs, exposing the application data model that the back end developer has either defined or imported from the back end. Data adapters are used to connect and access the back end data.

The data adapters understand the intricacies of the back end. The connectors are the key on how to talk to and fetch the data from the back end.

The bond between the data that comes from the back end via the data adapter and client facing APIs, is the map transformation engine. The three components are hosted in the Kony Fabric servers.

Components and Features of Object Services

The following describes the primary components and features of Object Services.

App Model

Mapper

Data Adapters

Sync Auto Generation

Binary Data Support

Architecture of Kony Fabric Objects Services

An overview of the Objects Services architecture follows.

Create an Object Service

To create an Object Service, you can use an existing identity provider or you can specify log-in endpoint details in the Object Service definition. After you create the Object Service, you can generate a data model from back-end LOB systems that already have their data model exposed as objects, or you can build a data model and map the objects to a back-end LOB system. You can also create a service-driven object from an existing Kony Fabric Integration Service or Kony Fabric Orchestration Service.

To create an object service, follow these steps:

  1. After you create a Kony Fabric app, click on the app.
  2. In the Configure Service tab, click the Identity service tab.
  3. Click Configure New, and create an identity service for Kony SAP Gateway. See How to Configure a New Kony SAP Gateway.

    4. To use an existing integration service, refer to How to Use an Existing Integration Service.

  4. Click the Objects service tab.
  5. Click Configure New.
  6. Click in the Name field, and type a name for the object service.
  7. Click the Endpoint Type field and select the endpoint that you want to use.
  8. Click the Security Level field and select the level of security you prefer.
  9. In the Identity Service for Backend Token field, select an existing identity service that is associated with your app to have Kony Fabric automatically add any backend security tokens received during authentication to the outbound request of this integration service.
  10. Under User ID and Password, provide valid credentials that you created while registering with Kony SAP services.
  11. Click in the Default Caller ID field, and provide the ID that Kony SAP Gateway uses for logging and auditing.
  12. Click in the Default Caller Group field, and provide the group ID that Kony SAP Gateway uses for logging and auditing. This information is optional.
  13. Click Test Login.

  14. Click the Advanced tab.

  15. If you want to specify a JAR file to associate with this service, select one from the Select Existing JAR drop-down menu, or click Upload New to add a new JAR file.
  16. If you want other identity services associated with your app to allow this service to access the identity session of the end-user at runtime, click the Select Dependent Identity Services drop-down menu and select the check box next to each identity service you want to use. This enables any operation to retrieve backend security tokens or other user profile data received during authentication and use it as part of the request sent to the backend target.
  17. Click Save & Configure.

Create Offline Objects

The Offline Objects feature enables you to download objects data from a Kony Fabric object service into a mobile device. This downloaded data can be used while the device doesn’t have network connectivity and can be synced later with the Kony Fabric object services backend. The Offline Objects feature uses the OData protocol, an open-sourced protocol to connect directly with object services without the need of another sync server in the middle. A user can use the Offline Objects feature with apps created using Kony Visualizer as well as apps that are developed natively.

For more information on Offline Objects, see Offline Objects Getting Started Guide, and Offline Objects API Reference Guide.

Generate a Data Model From a Back-end LOB System

In this procedure, you will generate a data model from a back-end LOB system that already has its data model exposed as objects.

To generate a data model from back-end LOB objects, follow these steps:

  1. Create a new object service. Follow the steps in Create an Object Service.
  2. Click Save & Configure.

    3. The data model configure screen for the object service appears.

  3. Click Generate.
  4. From the Import Objects from Backend screen, click the VTI_INTERNAL library.
  5. Select the VTI_SAMPLE_ORDERS object.

    6. Importing the VTI_SAMPLE_ORDERS object also imports the objects related to VTI_SAMPLE_ORDERS in the object hierarchy on the SAP back end.

  6. Click Next.

    7. The Import Objects from Backend screen shows the imported back-end objects and the names of the imported objects for the data model. You can edit the names of the objects for the data model.

  7. Click Generate.

    8. Kony Fabric generates the data model based on the back-end objects that you imported. The metadata discovery that is built in the Kony SAP Gateway identity service defines the object structure and the relationships between the objects.

    The SAP back end maintains a single media object that is shared between different objects. Kony Fabric imports the binaries for all the objects that you selected from the SAP back end as one media object in the data model.

  8. In the Data Model tab of the navigation pane, click the plus button next to the VTI_SAMPLE_ORDER object.

    9. Fields and Relationships appear under the VTI_SAMPLE_ORDER object.

  9. Click Fields.

    10. The list of fields in the VTI_SAMPLE_ORDER object appears in the Configure screen. You can change the name of the fields or modify the attributes . For example, you can change the primary key attribute. You cannot change the auto generated attribute.

  10. In the Data Model tab of the navigation pane, under the VTI_SAMPLE_ORDER object, click Relationships.

    11. The list of relationships for the VTI_SAMPLE_ORDER object appears. The VTI_SAMPLE_ORDER object has a many-to-one join with the VTI_SAMPLE_COMPANY object and a one-to-many join with the VTI_SAMPLE_ORDER_ITEM object. You can edit or delete the relationships, or add new relationships.

  11. In the navigation pane, click the Mapping tab.

    12. The Common Mapping configuration screen for the VTI_SAMPLE_ORDER object appears. The common mapping between a data model field and a back-end object field is applied to a transform request, response, or both, when methods are invoked on a back-end object. The double-headed arrow icon in the Type drop-down indicates that the mapping transformation is applied to both request and response. The right-arrow icon indicates only request mapping, and the left-arrow icon indicates only response mapping of the object.

  12. Click Save.

    13. You can now publish the Kony Fabric app as it is, or you can also configure the objects to be enabled for offline synchronization.

To enable synchronization for the application, follow these steps:

  1. In the Configure Services tab, click Synchronization.

    2. The Synchronization page appears.

  2. Click Configure New.
  3. In the Name text box, enter OrderSyncScope.
  4. In the Namespace text box, enter orders.
  5. Under Sync Strategy, use the default, OTA Sync.

    6. A persistent Sync strategy is not supported for a Sync scope that uses an object service as the data source type.

  6. Under Data Source Type, select Object Services.
  7. Click in the Select the service field, and then select the name of an object servicefrom the drop-down menu.

  8. Click Save.

    9. The objects that you defined in the Orders application are now enabled for offline synchronization.

  9. Publish the app. For information about publishing a Kony Fabric app, see Publish.

After you have generated the data model from the back-end objects that you imported, you can publish your app. Then provide the code that Kony Fabric generates to a mobile app developer. The mobile app developer integrates the code with platform SDKs and adds additional logic and modifies the presentation layer. The mobile app developer builds the client binary and publishes it to the enterprise app store.

At runtime, Kony Fabric is the middleware that talks to the back end, manages the integration, and filters, transforms and synchronizes the data it sends to the front-end clients.

Configure Binary Support for Objects

Kony Fabric manages binary data for offline access. For example, a work order that has instructions as an attachment. The binary Sync to Device Policy determines when the sync to the device from the back end needs to be triggered. The following are the Sync to Device Policy options that you can set:

To set the binary Sync to device policy for a Kony Fabric app, follow these steps:

  1. In the Configure Services tab, click Synchronization.
  2. Hover your cursor over the sync scope, click the Settings button, and then click Edit.
  3. Click Sync Objects.
  4. In the sync scope expand the Sync Objects tab and select the binary object. The name of a binary object from an SAP back end is media.
  5. Click the Binary Handling tab.

  6. Click the Sync to Device Policy field, and then select a policy option from the drop-down menu.

    7. The possible values are

  7. If you select Based on Record, click the Conditional Attribute field, and then slect an attribute from the drop-down menu.

    8. The sync will be triggered when the conditional attribute value is true.

  8. Click Save.

Build a Data Model and Map to Back-end Objects

The section shows you how to create a new data model, and then map the data model to the back end LOB.

The data model that you create is the data model that you want to provide to the client app developer. The data model will be provisioned on the end user's device, into which Kony Fabric will be pushing synchronized data. The mapping specifies how the app data model is populated from a back-end LOB system.

The advantage to creating a data model is that you can build a client application by using your preferred data model, and then populate the data model from a back end, regardless of the structure of the back end.

Create a Data Model

In this procedure, you will create a new data model, add objects to the data model, and then add fields to the objects.

To create a data model and add an object, follow these steps:

  1. Create a new object service. See Create an Object Service.
  2. Click Save & Configure.

    3. The Configure screen for the new object service appears.

  3. Click Configure New.
  4. In the Name text box, enter Order, and then click Save.

    5. In the Configure screen, the Order object appears in the list of objects.

  5. In the Data Model tab of the navigation pane, click the plus button next to the Order object.

    6. Fields and Relationships appear under the Order object.

  6. Click Fields.

    7. The empty fields list appears in the Configure screen.

  7. Click the Add button.
  8. In the Name column, click in the field and enter OrderID.
  9. In the Primary Key column, click in the field, and select True from the menu.
  10. Click the Add button.

    11. A new row appears in the fields list.

  11. In the Name column, click in the new row and enter Company.
  12. Repeat steps 10 and 11 to add the following fields to the Order object:

  13. Click Save.

To add the OrderItem object to the data model, follow these steps:

  1. In the Data Model tab of the navigation pane, click Data Model.

    2. The list of objects appears in the Data Model screen.

  2. Click the Add button.
  3. In the Name text box, enter OrderItem, and then click Save.

    4. The OrderItem object appears in the list of objects.

  4. In the Data Model tab of the navigation pane, click the plus button next to the OrderItem object.
  5. Click Fields.
  6. Click the Add button.
  7. In the Name column, click in the field and enter OrderID.
  8. In the Primary Key column, click in the field, and select true from the menu.
  9. Click the Add button.

    10. A new row appears in the fields list.

  10. In the Name column, click in the new row and enter ItemID.
  11. In the Primary Key column, click in the field, and select true from the menu.
  12. Click the Add button.
  13. In the Name column, click in the new row and enter Product.
  14. Click the Add button.
  15. In the Name column, click in the new row and enter Quantity.

  16. Click Save.

    You can also clone an app data model of an existing object service. Refer to Actions in objects services.

Configure the Relationships Between Objects

In this procedure, you will define the relationships between the objects in the Orders data model.

To configure the relationships, follow these steps:

  1. In the Data Model tab of the navigation pane, under the Order object, click Relationships.

    2. The Relationships screen appears.

  2. Click the Add button.

    3. The screen for configuring the relationships appears.

  3. Click in the Select Target Objects field, and then select the OrderItem object from the drop-down menu.
  4. Click in the Select Relationship Type field, and select One to Many from the drop-down menu.
  5. Under Specify Object Attribute Relationships, click in the Source Object Attributes field, and then select OrderID from the drop-down menu.
  6. Click in the Target Object Attributes field, and then select OrderID from the drop-down menu.

  7. Click Save.

Configure Common Mapping to the Fields on the Back End

The common mapping that you define between a data model field and a back-end object field is applied to a transform request, response, or both, when methods are invoked on a back-end object. The double-headed arrow icon in the Type drop-down menu indicates that the mapping transformation is applied to both request and response. The right-arrow icon indicates only request mapping, and the left-arrow icon indicates only response mapping of the object .

To configure the mapping, follow these steps:

  1. In the navigation pane, click the Mapping tab.

    2. The mapping configuration screen for the Order object appears.

  2. Click in the first Map to field. A drop-down menu appears. Select VTI_Internal. The business object in the back end.
  3. Click in the second Map to field. A drop-down menu appears. Click on the plus button next to VTI_SAMPLE_ORDERS, and then click on VTI_SAMPLE_ORDER.

    4. The Common Mapping tab shows that the Order object in your data model is mapped to the VTI_SAMPLE_ORDER table of the VTI_SAMPLE_ORDERS database in the backend object VTI_Internal.

  4. Click the Add button.
  5. Click in the first field under APP DATA MODEL FIELDS. A drop-down menu appears. Select OrderID.
  6. Click in the first field under VTI_SAMPLE_ORDERS FIELDS. A drop-down menu appears. Select ORDER_NUMBER.
  7. Click the Add button.
  8. Click in the second field under APP DATA MODEL FIELDS. A drop-down menu appears. Select Amount.
  9. Click in the second field under VTI_SAMPLE_ORDERS FIELDS. A drop-down menu appears. Select TOTAL_VALUE.
  10. Click the Add button.
  11. Click in the third field under APP DATA MODEL FIELDS. A drop-down menu appears. Select Company.
  12. Click in the third field under VTI_SAMPLE_ORDERS FIELDS. A drop-down menu appears. Select COMANY.
  13. Click the Add button.
  14. Click in the fourth field under APP DATA MODEL FIELDS. A drop-down menu appears. Select Description.
  15. Click in the fourth field under VTI_SAMPLE_ORDERS FIELDS. A drop-down menu appears. Select DESCRIPTION.
  16. Click the Add button.
  17. Click in the fifth field under APP DATA MODEL FIELDS. A drop-down menu appears. Select OrderType.
  18. Click in the fifth field under VTI_SAMPLE_ORDERS FIELDS. A drop-down menu appears. Select ORDER_TYPE.

  19. Under TYPE, click in the drop-down menu for OrderID and ORDER_NUMBER. Select the left-arrow to indicate response mapping of the object field.

In Common Mapping, you can also map an object in your data model to additional child objects in the back-end object hierarchy. To map an object to additional child objects in the back end, click Advanced, and then select the child objects in the hierarchy.

Configure Methods Mapping to the Fields on the Backend

Methods mapping is where you configure what the system should do for all the methods the client app will use. For example, a work order will use the Get, Post (create), Put (update), and Delete methods. When you perform a Get on a work order object, the mapping specifies the target object in the SAP back end and the method you can use against that object. And you can control what gets mapped on the request to SAP, and what gets mapped on the response.

To configure the methods mapping, follow these steps:

  1. In the mapping screen, click the Methods tab.
  2. Click the Add button.
  3. Click in the Data Model Verb field, and then select Get from the drop-down menu.
  4. Use the default Verb Security Level, Authenticated App User.

    5. The Verb Security Level specifies how the client must authenticate to the verb. You can restrict access to this verb to only authenticated app users that have successfully authenticated using an Identity service. An anonymous app user verb allows access from a trusted client that has the required App Key and App Secret, but the client does not need to authenticate the user through an identity service. Set the security level to Public to allow any client to access this verb without any authentication requirement.

  5. Click in the Backend Object Verb field. Click the plus button next to VTI_SAMPLE_ORDER, and then select Get.

    6. Object Services provides built-in variants of the get verb. Click the get verb in the navigation page to configure the mapping of the variants of the get verb. The built-in variants of the get verb are getAll, getbypk, getupdated, getbatch, and getdeleted. The get verbs are not mapped individually. All the get verbs have a common request mapping and a common response mapping.

  6. Click Add Mapping.

    7. The method mapping configure screen appears. The Request Parameters tab lists the parameters of the method that you can use for the VTI_SAMPLE_ORDER object.

  7. Select the Apply Common Mapping check box if it is not selected.

    8. Selecting the check box applies common mapping of the object to this verb. To override the common mapping, clear the check box and specify a custom mapping in Request Mapping and Response Mapping.

  8. Click in the Value field for the $filter parameter.

     The & and = operators are not supported in values for OData string key ($filter).

  9. Enter the expression orderStatus ne 'Draft'.

    10. This will filter the orders that have an order status of Draft.

  10. Click Request Mapping.

    11. If you do not apply common mapping of the object to the get verb, this is where you specify a custom mapping on the request to SAP. Common mapping by default maps one-to-one the data model method to the method of the target object in the back end.

  11. Click Response Mapping.

    12. If you do not apply common mapping of the object to the get verb, this is where you specify a custom mapping on the response to SAP.

  12. Click Test.

    13. The Test panel appears. You can use the Test panel to test the mapping for a method. To test the mapping, enter the query parameters, select an environment, enter the headers and header values that you want to include with the test. Then, in Request Payload, enter values for the fields for which you want to test the mapping, and then click Send.

  13. In the navigation pane, click the Orders object.
  14. Click Advanced.

    15. The Include Related Objects field and the Verb Security Level field appear. The Include Related Objects setting specifies which part of the App Model Object's hierarchy can be handled by the verb. This information helps in optimizing the number of calls to the back end in case the verb also deals with other objects in the hierarchy. You can multi-select multiple objects in the drop-down to specify the information.

  15. Click Save.

You can enable the application for offline synchronization, publish the application, and then provide the code that Kony Fabric generates to a mobile app developer.

Adding Custom Verbs for SAP Object Service

SAP Object Service has provided the ability to add custom verb names and map it to an operation of a backend object. You can now create your own custom verb in addition to the existing verbs (Create, Read, Update, Delete and Partial Update) and map to a backend business operation.

To create a custom verb, follow these steps:

  1. In the Mapping screen. click the Methods tab.

  2. Click the Add button.

  3. Click in the Data Model Verb field. A drop-down menu appears. Select custom.
  4. Provide the Custom Verb name.
  5. Use the default Verb Security Level, Authenticated App User.

  6. Select the Library, it automatically populates the list of data and business object hierarchies available.
  7. Select the Business Object from the drop-down list.
  8. Select the verb name from the Verb drop-down list and click SAVE.

    The created custom verb is successfully added to the list of existing verbs.

  9. Select the created custom verb from the Mapping section in the left pane.

  10. Click Request Mapping.

    The Apply Common Mappings check box is unchecked as the backend object being mapped is different from the mapped application model object. If the check box is unchecked, you should specify a custom mapping on the request to SAP to map the backend object to application model object. The custom verb will be available to the end users similar to the other verbs when the same app is published and tested from the rest client.

  11. Click Response Mapping.

    If you do not apply common mapping of the object, you should specify a custom mapping on the response to SAP.

  12. Click Test.

    You can use the Test panel to test the mapping for a method. To test the mapping, enter the query parameters, select an environment, enter the headers and header values that you want to include with the test. Then, in Request Payload, enter the values for the fields for which you want to test the mapping, and then click Send.

    If the test is successful, the end users can invoke the created custom verb from their app post publish.

Create a Service-Driven Object Service

You create a service-driven object from existing Kony Fabric Integration services or Kony Fabric Orchestration services. If you have built Integration or Orchestration services in Kony Fabric, you can use Object Services to build objects out of those services. A service-driven object service abstracts some of the API complexity by creating a layer in between the app data model mapped to Integration services on the back end.

Create a service-driven object by using an existing Kony Fabric Integration service or Orchestration service to connect to a back end. These are objects that you can define from existing API's; for example, REST, SOAP, and XML. You use one API to create the object in the back end, and one API to get the object from the back end.

For example, instead of the client developer having to call get accounts or modify accounts APIs, you generate client code to give the client developer who has an account object that has all that knowledge built into it. The client developer programs against the object and does not have to call APIs.

In Kony Fabric you see all the attributes the API returns, and then you generate or enter the fields of the objects that you map to the attributes from the API. If your application needs data that does not exist on any back end, the service-driven object can also be the storage provider for a mobile app.

Example: Create a Service-Driven Object

The section uses an example to show and explain how a service-driven object works. In the example, a service-driven object is created for a defect tracking system. For example, you can work with an existing defect object or create a new defect object.

The first step in creating a service-driven object for the defect management system is to create the integration services. An integration service definition comprises the metadata or the configurations required to exchange data with the external data source. The defect management system is a SOAP service, so you upload the WSDL to create an integration service from that WSDL, and then choose the methods that you want to use.

With the integration services, you can develop a mobile app traditionally. You now have the REST APIs that you can use to build the mobile app by using the Kony Fabric SDK. To take it further, you can use Object Services to construct your data model, get the methods, and map those methods to the API. The object services layer is built on top of the integration services and gives you the generated object code, which reduces the amount of logic you have to write in your mobile app.



Scenario 1:  For the Salesforce back end while hitting the Test  tab in Object Services, which are created on top of the integration services by the identity provider, the following are the headers that are to be passed from the admin console:
   x-kony-sfdc-access-token
   x-kony-sfdc-instance-url

And for x-kony-sfdc-access-token: The token, which is generated from the integration service that has Bearer in the beginning should be removed and then sent the request.


Scenario 2:  For Salesforce back end while hitting the Test tab in Object services, which are created on top of the integration services with specify endpoint, use  Authorization in the headers that you can get from using log-in service. To hit the both the above scenarios from the RestClient or PostMan, only X-Kony-Authorization should be sent as a header.

Create the Integration Service

The app for the defect tracking system requires two integration services. The first integration service gets a token from the back end. This token is needed to access the data in the defect management system. The second integration service is for performing operations on the defect management system.

DigiteLoginToken Service

The first integration service is named DigiteLoginToken. The type of integration service is SOAP. The given base URL is specified, and the given WSDL URL is specified.

The DigiteLoginToken service has one operation, LoginForToken0. The operation provides the parameters for the username and password for the defect management system.

If you click Fetch Response, the defect management system back end returns a token in the output result. The token that must be sent along with every request to access data in the back end.

Digite Service

The second integration service is named Digite. The type of integration service is SOAP. The given base URL is specified, and the given WSDL file to upload to the Kony Fabric app is specified.

The Digite integration service has operations for accessing and performing actions on the defect management system.

The getDefectDetailsById operation includes the DigiteLoginToken parameter for passing the token that the back end expects with every request. The scope of the DigiteLoginToken parameter is session. This means that Kony Fabric picks up the parameter up from the session that is created for the app.

If you click Fetch Response, the service sends to the defect management system back end the DigiteLoginToken that was retrieved earlier. The service also sends the defect ID and project parameters. The back end will respond by sending all the details related to the specified defect ID, MBaaS6262, in the specified project, MBaaS.

Traditional App Development and Object-Based App Development

With the integration services complete, you have imported the WSDL from the defect tracking system and turned it into a REST API. You can stop at this point and proceed to develop the client app in the traditional way by simply calling those new REST APIs from the client app. Or you can go to the Objects tab and perform a few extra steps to turn the WSDL into a service-driven object, and reduce the amount of logic that you must write in the client app.

The following diagram shows the Object Services layer that is built on top of these other Kony Fabric services. When using Kony Fabric object services, the client developer is given an SDK and the generated client object code. This reduces the amount of logic that the client developer must write, and significantly reduces the effort required to develop the mobile app.

 

Create a Service-Driven Object

Now we will go to the Objects and create a service-driven object from the integration services. The first step is to create an object service.

To create the object service, follow these steps:

  1. Click the Objects service tab.
  2. Click Configure New.
  3. Click in the Name field, and enter the name DigiteObjectSvc.
  4. Click in the Endpoint Type field. A drop-down menu appears. Select Integration & Orchestration Services.
  5. Click Save & Continue.
  6. Click Generate.

    7. The Generate App Data Model from Existing Services screen appears.

  7. Click the Add button.
  8. Click in the Object Name field, and enter Defect.
  9. Click in the Service Name field. A drop-down menu appears. Select the Digite integration service.
  10. Click in the Operation Name field. A drop-down menu appears. Select getDefectDetailsById.

  11. Click Generate.

    12. Kony Fabric generates the objects and the data model based on the getAccount and getContact operations in the Salesforce integration service. All the fields for the objects are populated from the union of what is sent to the specified operation and what is returned from the operation.

Now add three additional fields to the Defect object for this defect management system.

To add fields to the Defect object, follow these steps:

  1. In the Data Model navigation pane, click the plus button next to Defect, and click Fields.
  2. Click the Add button.
  3. In the new field that is added to bottom of the list, enter FieldValueString for the name of the new field.
  4. Click the Add button.

  5. In the new field that is added to bottom of the list, enter Action for the name of the new field.
  6. Click the Add button.
  7. In the new field that is added to bottom of the list, enter Comment for the name of the new field.
  8. Scroll up to the ID field.
  9. For the ID field, click Primary Key. Select true.
  10. Click Save.

Now configure change tracking for the Defect object. Change tracking tracks the changes in the server database.

To configure the change tracking, follow these steps:

  1. In the Data Model navigation pane, click Change tracking for the Defect object.
  2. Click in Batch Mode. A drop-down menu appears. Select No batching to indicate that the back end does not support batching.
  3. Click Save.

Now map the verbs for the Defect object. To perform operations beyond the basic create, read, update, and delete operations, you can create custom verbs.

To map the verbs for the Defect object, follow these steps:

  1. In the navigation pane, click the Mapping tab, and then click the Defect object.
  2. Click the Add button.

    3. The verb mapping configuration screen for the Account object appears.

  3. Click in the Data Model Verb field. A drop-down menu appears. Click Create.
  4. Under Verb Security Level, use the default, Authenticated App User.

    5. The Verb Security Level specifies how the client must authenticate to the create verb. Authenticate App User restricts access to the create verb to users that have successfully authenticated using an Identity service. You can also set the security level to Anonymous App User and Public.

  5. Click in the Services field. A drop-down menu appears. Select the Digite integration service.
  6. Click in the Operations field. A drop-down menu appears. Click createAccount.
  7. Click Save.
  8. Repeat steps 2 through 7, and map the data model verb update to the updateDefect operation.
  9. Repeat steps 2 through 7, and map the data model verb partialupdate to the updateDefect operation.
  10. Repeat steps 2 through 7, and map the data model verb get to the getAllDefects operation.

    11. The mapping for the verbs is automatically generated. Mapping is auto-generated only when the dataset name of integration services and object name matches. The mapping is populated in the Request Mapping and Response Mapping tabs based on the input and output of the operations. To specify custom mapping, clear the Apply Autogenerated Mapping check box.

    You can view the mapping for a verb by clicking the verb on the Mapping tab in the navigation pane. Request mapping is the parameters that are mapped from the device side to the back end. Response mapping is the parameters that the backend sends to the object's fields.

  11. In the navigation pane, under the Defect object, click the get verb.
  12. Click Get Variants.

    13. The mapping configuration for the get verbs appears. Object Services provides built-in variants of the get verb. The built-in variants of the get verb are getAll, getbypk, getupdated, getbatch, and getdeleted. The get verbs are not mapped individually. All the get verbs have a common request mapping and a common response mapping.

  13. Click in the Service Name field for the getbypk verb, and select Digite.
  14. Click in the Operation field for the getbypk verb, and select getDefectDetailsById.

    15. A green check mark indicates that the operation mapping has succeeded.

  15. Click Save.

In addition to the built-in verb options, you can also create custom verbs for an object. For example, you can create the custom verb assign, and map it to the assignDefect operation on the back end.

To create and map the custom verbs for the Defect object, follow these steps:

  1. In the navigation pane, on the Mapping tab, click the Defect object.
  2. Click the Add button.
  3. Click in the Data Model Verb field. A drop-down menu appears. Click custom.
  4. Click in the Custom Verb Field and enter assign.
  5. Under Verb Security Level, use the default security level that is selected, Authenticated App User.
  6. Click in the Services field. A drop-down menu appears. Select the Digite integration service.
  7. Click in the Operations field. A drop-down menu appears. Select assignDefect.
  8. Click Save.

    9. The mapping for the verbs is automatically generated by default. The mapping tabs show the automatically generated mapping of the object applied to this verb.

  9. Repeat steps 2 through 8. Create the custom verb search, and map it to the searchDefect operation.
  10. Repeat steps 2 through 8. Create the custom verb route, and map it to the routeDefect operation.
  11. Repeat steps 2 through 8. Create the custom verb getDefectsByMemberId, and map it to the getDefectsByMemberId operation.

  12. Click Save.

To validate the object service, follow these steps:

  1. In the Configure Services tab, click the Objects service tab.
  2. Hover your cursor over the object service, click the Settings button to display the context menu, and then click Validate.

To enable synchronization for the application, follow these steps:

  1. In the Configure Services tab, click the Synchronization service tab.

    2. The Synchronization page appears.

  2. Click Configure New.
  3. In the Name text box, enter a name for the synchronization service.
  4. In the Namespace text box, enter Defect.
  5. Under Sync Strategy, use the default, OTA Sync.

    6. Note that a persistent sync strategy is not supported for a sync scope that uses an object service as the data source type.

  6. Under Data Source Type, select Object Services.
  7. Click in the Select the service field. Select the service-driven object service, DigiteObjectSvc.
  8. Click Save.
  9. In the Configure Services tab, click Synchronization service tab.
  10. Click the Settings button and click Validate all.

    11. The objects that you defined in the object service for application are now enabled for offline synchronization.

  11. Publish the app. For information about publishing a Kony Fabric app, see Publish.

After you publish the app, you download the client-side object code for the sync-enabled app that Kony Fabric generates, and provide it to the mobile app developer. The mobile app developer integrates the code with platform SDKs, adds additional logic and creates the presentation layer. The mobile app developer builds the client binary and publishes it to the enterprise app store.

At run time, Kony Fabric is the middleware that talks to the back end; manages the integration; and filters, transforms, and synchronizes the data it sends to the front-end clients.

Create a Storage Object Service

With Object Services, you can create an object on Kony Fabric for storing data for mobile apps. You can use Kony Fabric as a storage provider if your application needs limited data that is not available on an enterprise backend and does not exist anywhere else.

For example, a Kony Fabric storage object is ideal for a restaurant survey mobile app. In the restaurant, the service staff request that a customer fill out the survey on a device provided by the restaurant. The survey data that the customer enters is stored in a database on the Kony Fabric back end. The service staff and customer cannot access the survey results. The restaurant manager can then retrieve the survey data and use it for analysis and reporting.

The Kony Fabric developer creates a storage object service and defines the data model with the fields that the mobile app requires. Upon publishing the Kony Fabric app, Kony Fabric creates a data schema in the back end based on the data model and instantiates a new self-contained database. The operations that the mobile app performs are performed on the database.

Use Cases

The following describes use cases for a Kony Fabric application with storage object services.

Home Owner’s Association App

A home owners association that maintains rules to ensure the neighborhood always looks nice. For example, members of the association are required to cut their grass, maintain the landscaping, and keep up the appearance of their house. The association can fine a member any time for a significant violation, but what they typically do is conduct a house-by-house assessment every two years. A representative of the association walks around each house and inspects it. The inspector documents issues with pictures and provides the homeowner a report on what they have to fix.

To streamline this process, the association wants to create an iPhone and iPad app to help with the assessments. The inspector will go to the next house and create a new assessment record that contains:

The association representative then inspects the house and writes up any violations. Each record of violation contains:

To build this Kony Fabric app, the Kony Fabric developer first defines the data model that the mobile app requires. The following describes the definition of the data model.

The Assessments object has the following fields:

The Violations object has the following fields:

The ViolationImages object has the following fields:

The ViolationTypes object has the following fields:

The ViolationTypes object is used to populate a dropdown menu in the violation entry screen.

The following relationships are established between the objects:

Restaurant Customer Survey App

A food service company that has several restaurants needs a way to get responses from customers to evaluate the performance of their products and services and benchmark the indices. A mobile survey app is an effective tool to get feedback from customers.

The responses generated from the survey app can help the company to target the right set of customer segments, and appropriately position their products for the target segments. These are key inputs for the go-to-market strategy for the company.

The following describes how the survey app is used by a restaurant:

  1. A member of the service team at the restaurant asks a customer to participate in the survey. The service team member explains that the objective of the survey is to improve the products and services that the restaurant offers. The restaurant may offer a coupon as an incentive to the customer.
  2. The customer begins the survey by entering her personal data, such as name, email address, and phone number.
  3. The customer selects one of the categories of the survey. The categories are Food, Restaurant, and Service.
  4. The customer responds to the survey questions for the chosen category.
  5. When the customer clicks Done, the customer's response are recorded in the Kony Fabric storage object on the back end. The data model for app defines the storage objects that store the customer data.
  6. The customer completes the questions for the remaining categories of the survey.
  7. The restaurant manager retrieves the results of the customer survey for his restaurant. Only users who have the role of manager can access the results of the customer survey.

There are two personas that use the survey app:

Survey App Data Model

The following relationships are established between the objects:

To build this Kony Fabric app, the Kony Fabric developer first defines the data model that the mobile app requires. The following describes the definition of the data model.

SurveyTable object:

SurveyTypeTable object:

QuestionTable object:

QuestionsChoiceTable object:

SubmissionTable object:

AnswerTable object:

CustomerTable object:

Building the Survey App

John is assigned the task of creating back-end services for the Survey app.

  1. John signs in to Kony Fabric, creates a new Kony Fabric app, and then clicks Objects.
  2. John enters the name of the object service to create, selects the Endpoint type Storage, and configures the security level.
  3. John creates the data model. John proceeds by creating the required tables and fields, and defining the primary keys for the tables. John then defines the relationship between tables.
  4. Once John has created the data model, he clicks the Mapping tab. He clicks on the Get method to create mapping for the Get method. John can add ODATA filters. The request and response mapping are primarily a one-to-one mapping between the app data model and the Kony Fabric database. All the other methods have only Request and Response mapping.
  5. John then configures an OAuth2 identity service for the mobile app.
  6. John publishes the Kony Fabric app to a runtime environment.
  7. John then uses Kony Visualizer to create a new mobile app that uses the storage object services. The user experience of the mobile app is designed to collect survey information from restaurant customers.

Restaurant service staff can now use their Google credentials to sign in to the survey app and the storage object service honors the authentication levels. Any object service that is configured as Authenticated allows access to only Authenticated users. Note that all the tables for the app are created when the Kony Fabric app is published.

Reuse the Storage Object Service

John is then asked to build a mobile app for the restaurant managers. The manager app is capable of pulling out all the data from the Kony Fabric storage object database and showing the results.

  1. John signs in to Kony Fabric and creates a new Kony Fabric app.
  2. John clicks Objects, and then clicks Use Existing.
  3. John selects the Storage object service that he created for the restaurant survey app.

The Use Existing option copies the app data model to the new Kony Fabric app and gives access to the same back end (instance) of the storage object database. All the object services created here for the restaurant manager app will point to the same object and data that was created by the restaurant survey app.

Clone the Storage Object Service

If John is asked to create another survey app for another restaurant location, John would clone the storage object service that he created for the first restaurant. Only the app data model is copied for the new app and the back-end data is not shared between the two survey apps.

You can also clone an app data model of an existing object service. Refer to Actions in objects services.

How to Create a Storage Object Service

You can create a Storage object service for a Kony Fabric app if you want to create an object on the Kony Fabric back end for storing data for mobile apps. You can use Kony Fabric as a storage provider if your mobile app needs limited data and an enterprise back end is not available to store the data.

The following is an exercise that shows you how to create a storage object service for a Kony Fabric app. This Kony Fabric app is used by a mobile app for administering students, teachers, and the subjects that the students study.

Create a Kony Fabric App

  1. On the Applications page, click Add New.

    2. The Configure Services Identity tab appears.

  2. Click in Edit App Name button to enter a unique name for the app. For example, SampleStorageObject.
  3. On the Identity tab, configure a new identity service or use an existing service. To learn how create an identity service, see Identity. To learn how to use an existing identity service, see How to Use an Existing Identity Service.

    4. The following identity providers are not supported for Storage Services: Microsoft Active Directory, Open LDAP, Active Directory Federation Services (ADFS) over SAML, and Azure SAML.

  4. Click the Objects service tab.
  5. Click Configure New.
  6. Click in the Name field, and enter a name for the object service. For example, SampleStudentStorage.
  7. Click in the Endpoint Type fieldand then click Storage in the drop-down menu.
  8. Under Security Level, use Authenticated App User.
  9. Click in the Authentication field, and then select the identity provider that you want to use.

    10. This links the Identity provider to the object service.

  10. Click in the Description field, and enter a description for the object service.

  11. Click Save & Configure.

    12. The Configure page for the object service appears.

Create a Data Model for the Storage Service

  1. Click Configure New.
  2. In the Name text box, enter Student, and then click Save.

    3. In the Configure screen, the Student object appears in the list of objects.

  3. In the Data Model tab of the navigation pane, under the Student object, click Fields.

    4. The fields that Kony Fabric generates by default appear. The fields are populated in the database when you save the object service.

  4. Click the Add button.
  5. In the Name column, click in the field and enter Id.

    6. The name of a field can be a maximum of 25 characters.

  6. In the Primary Key column, click in the field, and select true from the menu.

    7. When you set the Primary Key attribute to true for a field, the Unique attribute is automatically set to true.

  7. In the Autogenerated column, click in the field, and select true from the menu.

    8. When you set the Autogenerated attribute to true for a field, the Type attribute is automatically set to number.

  8. Click the Add button.

    9. A new row appears in the fields list.

  9. In the Name column, click in the new row and enter Name.
  10. Click Save.

  11. Click Mapping.

    12. The list of corresponding verbs created for this object appears.

View the SQL Scripts

If you export the Kony Fabric app, you can see the SQL scripts that are generated for the data model. In the exported app, in the ObjectService folder, there is a _Flyway folder. Inside the _Flyway folder are SQL scripts that correspond to different database types. Currently, Storage Services supports only MYSQL. Flyway is a tool that Kony Fabric uses to run the SQL scripts on the server. In the MYSQL folder, you can find the corresponding schema file that Kony Fabric generated for the data model. In an editor, you can see the Student table and fields that Kony Fabric created and the primary key, and the constraints that have been added to that table.

Test the Runtime Service

After you publish the app, you can use App Services to test the run-time of the storage service. This represents how the mobile app on the device will interact with the runtime of the service.

For example, in App Services, for Object Services, select the Student@create operation for the sample student app, and then click the service URL below the operation. In the Service Details, for Input Parameters, enter {name: "S1"} and click Get Response. In the Response Body, the return code indicates that the student record was created. To update a record, select the Student@update operation and enter {name: "S2". Id:1} in Input Parameters. To retrieve the student records, select the Student@get operation, and without specifying any filters, click Get Response. In the Response Body, the student records are returned. Note that the fields that Kony Fabric generates by default, CreatedDateTime and LastUpdatedDateTime, recorded when the student record was created and when the record was updated.

Add a Subject Object to the Data Model

  1. Click the Data Model tab, and then click Data Model.
  2. Click Add.
  3. In the Name text box, enter Subject, and then click Save.

    4. In the Configure screen, the Subject object appears in the list of objects.

  4. In the Data Model tab of the navigation pane, click the plus button next to the Student object.

    5. Fields and Relationships appear under the Student object.

  5. Click Fields.

    6. The fields that Kony Fabric generates by default appear. The fields are populated in the database when you save the object service.

  6. Click the Add button.
  7. In the Name column, click in the field and enter Id.
  8. In the Primary Key column, click in the field, and select true from the menu.
  9. In the Autogenerated column, click in the field, and select true from the menu.
  10. Click the Add button.

    11. A new row appears in the fields list.

  11. In the Name column, click in the new row and enter name.
  12. Click Save.
  13. Click Data Model, and then click Add.

    14. Now add an object that records the student to subject mapping; that is, which subjects a student is studying.

Add a Student/Subject Object to the Data Model

  1. In the Name text box, enter Student_Subject, and then click Save.

    2. In the Configure screen, the Student_Subject object appears in the list of objects.

  2. In the Data Model tab of the navigation pane, click the plus button next to the Student_Subject object.

    3. Fields and Relationships appear under the Student_Subject object.

  3. Click Fields., and then click the Add button.
  4. In the Name column, click in the field and enter Id.
  5. In the Primary Key column, click in the field, and select true from the menu.
  6. In the Autogenerated column, click in the field, and select true from the menu.
  7. Click the Add button.

    8. A new row appears in the fields list.

  8. In the Name column, click in the new row and enter Student_id.
  9. In the Type column, click in the field, and select Number from the menu.
  10. Click the Add button.
  11. In the Name column, click in the new row and enter Subject_id.
  12. In the Type column, click in the field, and select Number from the menu.
  13. Click Save.

Create an Index

You can performance tune the object service by creating indexes on the objects.

  1. In the Data Model tab of the navigation pane, click the plus button next to the Student object.
  2. Click Indexes, and then click Add.

    3. The index configuration screen appears.

  3. In the Name column, enter a name for the index.
  4. In the Description column, enter a description.
  5. Click in the Fields column. A drop-down menu of fields in the object appears. Select Id, Name, and LastUpdatedDateTime.

    6. The collection of records in the object are indexed by the fields that you select.

  6. In the Unique column, select true to indicate that a field that you selected has a unique key.

    7. An index that has multiple fields is called a clustered index. A clustered index should have a unique key as the first field. For example, Id is a unique key.

  7. Click Save.

Configure the Relationship Between Objects

Now you can define the relationships between the objects in the data model.

  1. In the Data Model tab of the navigation pane, under the Student object, click Relationships.

    2. The Relationships screen appears.

  2. Click the Add button.

    3. The screen for configuring the relationship appears.

  3. Click in the Select Target Objects field. A drop-down menu appears. Select the Student_Subject object.
  4. In the Select Relationship Type field, a storage service currently supports only a One to Many relationship.
  5. Under Specify Object Attribute Relationships, click in the Source Object Attributes field. A drop-down menu appears. Select Id.
  6. Click in the Target Object Attributes field. A drop-down menu appears. Select Student_Id, and then click Save.
  7. Under the Subject object, click Relationships.
  8. Click the Add button.
  9. Click in the Select Target Objects field. A drop-down menu appears. Select the Student_Subject object.
  10. Under Specify Object Attribute Relationships, click in the Source Object Attributes field. A drop-down menu appears. Select Id.
  11. Click in the Target Object Attributes field. A drop-down menu appears. Select Subject_Id.

  12. Click Save.

If you export the Kony Fabric app at this point, you will see the SQL scripts that correspond to the objects that you added and the relationships that you defined.

After you publish the app, you can use App Services to create a subject. For example, select the Subject@create operation and enter {name: "Physics"} in Input Parameters. Then you can select the Student_Subject@create operation and enter {name: "Student_id:1, Subject_id:1"} to add a record to the Student_Subject table. You can use the Student_Subject@get operation to query the Student_Subject table and verify that the record was created.

Add a Teacher Object to the Data Model

  1. In the navigation pane, click the Data Model tab of the navigation pane, and then click Add.
  2. In the Name text box, enter Teacher, and then click Save.
  3. In the navigation pane, click the plus button next to the Teacher object

    4. Fields and Relationships appear under the Teacher object.

  4. Click Fields., and then click the Add button.
  5. In the Name column, click in the field and enter Id.
  6. In the Primary Key column, click in the field, and select true from the menu.
  7. In the Autogenerated column, click in the field, and select true from the menu.
  8. Click the Add button.

    9. A new row appears in the fields list.

  9. In the Name column, click in the new row and enter name.
  10. Click the Add button.
  11. In the Name column, click in the new row and enter Subject.
  12. Click Save.
  13. In the Mapping tab of the navigation pane, click the plus button next to the Teacher object.
  14. Click the get verb, and then click the OData Query Options tab.

    15. The OData Query Options that object services supports for the read operation appear in the Configure screen. For example, you can use the $skip option to return all records in the table except the top five, or you can use the $top option to return only the top five records.

Add Security Attributes Profiles to the Request Input Parameters

When a user logs in to a mobile app, the logon can invoke a custom Kony Fabric identity service. The response to the back-end logon contains security attributes for the signed in user. For example, the response contains the user_id attribute of the logged on user.

When you link an object service to an identity service, the identity session parameter can be consumed in an object service. In Object Services, you can dynamically pick up the fields received in the user attributes of the logon response from the backend, and use those fields as input parameters for operations, such as create and update.

Using attributes from user profiles in request input parameters from Kony Fabric can also help to preserve sensitive data from the back end on Kony Fabric rather than sending it to the mobile app. This reduces the vulnerability of hacking of sensitive data on the mobile device.

For example, you can add an input parameter for the create operation that uses the CreatedBy field in the data model. You specify that the value of the input parameter is an Identity type. This indicates that the input parameter uses an attribute of the user security profile from the identity service that is linked to the object service. When a user of the mobile app creates a Teacher record in the storage object, Kony Fabric picks up the user's user_id from the security profile in the identity service and adds it to the new record. Along with the Name, Id, and Subject for the Teacher, the record indicates who created the record.

To add an identity profile to an input parameter, do the following:

  1. In the navigation pane, click the Mapping tab, and then click the plus button next to the Teacher object.
  2. Click the create verb.

    3. The Request Input Parameters tab appears in the Configure screen. You define how to use the user profile data by selecting a verb and the data model field that you want to map to the user profile data.

  3. Click Add.
  4. In the Data_Model_Field column, click the drop-down menu, and select the CreatedBy attribute.
  5. Click the drop-down menu in the Value column, and select identity.

    6. An identity value indicates that Kony Fabric will retrieve the value specified from the user's security profile in the identity service that is linked to the object service.

  6. In the text box next to the identity value, enter profile.user.id.

    7. This specifies that Kony Fabric will populate the value of the input parameter from the user's security profile.

  7. Click Add.
  8. In the Data_Model_Field column, click the drop-down menu and select the LastUpdatedBy attribute.
  9. Click the drop-down menu in the Value column, and select identity.
  10. In the text box next to the identity value, enter profile.user.id.

  11. Click Save, and then in the navigation pane, click the update operation.
  12. Click Add.
  13. In the Data_Model_Field column, click the drop-down menu in the Data_Model_Field column, and select the LastUpdatedBy attribute.
  14. Click the drop-down menu in the Value column, and select identity.
  15. In the text box next to the identity value, enter profile.user.id.
  16. Click Save.
  17. In the navigation pane, under the Teacher object, click the update operation.
  18. Click Add.
  19. In the Data_Model_Field column, click the drop-down menu, and select the LastUpdatedBy attribute.
  20. Click the drop-down menu in the Value column, and select identity.
  21. In the text box next to the identity value, enter profile.user.id.
  22. Click Save.

After you publish the app, you can use an API testing program, such as Postman, and create a Teacher record to test the run-time of the storage service. You can then use the Teacher@get operation to query the Teacher table and verify that the record was created. The Response Body returns the Teacher record that you created. Note that Kony Fabric added the fields that you specified in the input parameters, CreatedBy an LastUpdatedBy, to the record with the identity of the user who created the record.

Storage Service Usage Notes and Data Constraints

The following describes usage notes, guidelines, limitations, and workarounds for Storage Services.

Supported Identity Provider Types

The following identity providers are not supported for Storage Services:

Data Constraints

Testing Storage Objects from Kony Fabric

After you have published a storage service, you can test the service from Kony Fabric. Only the published state of the storage service is tested. Changes that you make in the service designer that you have not published cannot be tested.

To test a published storage service, do the following:

  1. In the Mapping tab for a storage service, click a verb (for example, get).
  2. In the Configure screen, click the Test tab.
  3. Click Test.

Storage Service SQL Scripts

When you define objects in a storage service and save the service, Kony Fabric creates a SQL script file that contains all the data definition statements that you generated since you last saved the service. For example, the first time that you save the service, the data definition statements are saved in the SQL file named V1_MYSQL. The next time that you save the service, the data definition language (DDL) statements are saved in the SQL file named V2_MYSQL. Each SQL file can contain multiple DDL statements. For example, a SQL script that contains statement that creates the table and a statement that defines constraints, such as a unique key or a relationship with another table.

When you publish the Kony Fabric app, a SQL script file is created for each DDL statement. Each script file contains one statement. For example, before publishing, when you save the Kony Fabric app, Kony Fabric creates a SQL script file named V1_MYSQL. This SQL script file contains four statements. When you publish the app, Kony Fabric creates a SQL script file for each statement in V1_MYSQL. For example, V1.1_MYSQL, V1.2_MYSQL, V1.3_MYSQL, and V1.4_MYSQL.

Kony Fabric creates an individual script file for each statement because rollback support is not available. If a SQL script file fails, there is only one statement to troubleshoot and fix.

When you export a Kony Fabric app, you can see the SQL scripts that the storage service generated for the data model. In the exported app, in the ObjectService folder there is a _Flyway folder. Inside the _Flyway folder are SQL scripts that correspond to different database types. Currently, Storage Services supports only MYSQL. Flyway is a tool that Kony Fabric uses to run the SQL scripts on the server. In the MYSQL folder, you can find the corresponding schema file that Kony Fabric generated for the data model.

Data Model Changes and Republishing Errors

The following describes scenarios in which republishing a storage service will fail after making certain changes to the data model.

In these scenarios, you cannot roll back the changes that caused the publish to fail. To repair the data model so that you can republish the app, do the following:

  1. Export the Kony Fabric app.
  2. Edit the SQL script and revert it to the original definition.
  3. Import the Kony Fabric app that contains the edited scripts.
  4. Publish the Kony Fabric app.

If you delete a field from a data model and republish the storage service, any data in the deleted field is removed from the storage object.

Health Check for Storage Services

The Kony Fabric health-check API include properties that denote the health of published storage services. The health-check API include properties that report if schema updates have been applied successfully, the current schema version, and the name of the SQL script file.

The following is the health-check URL format:

https://<Environment_Name>.konycloud.com/admin/healthcheck?output=json&force=true

The following is a sample JSON output from the health-check API. The properties that denote the health of published storage services are highlighted. 

 
{
   "healthDetail": {
      "Static Resources Location": "PASSED",
      "Access to Cache": "PASSED",
      "Access to Deployment Storage": "PASSED",
      "Cloud Environment Identification": "PASSED",
      "Access to Reporting Queue": "PASSED",
      "Access to Device DB": "PASSED",
      "Security Credentials": "PASSED",
   },
      "healthCheck": "PASSED",
      "storage_health": [{
         "version_rank": 3,
         "success": true,
         "service_name": "StorageService1207t20",
         "schema_name": "StorageService1207t20_ee82885b",
         "version": "1.2",
         "script": "V1.2__MYSQL.sql",
         "installed_rank": 3
	}],
	"Console-Version": "MIDCloud-QA-7.1.0_v201607051517_r18",
	"Gateway-Version": "5.6.72.0"
}

Export/Import of Storage Objects

You can download the data stored in a storage object through the admin server console. Users can upload their records and update the existing records using the export/import options.

Export storage objects data to a .csv file

To export or import data from storage objects, follow these steps

  1. Navigate to admin server console, and click on Object Services.
  2. The Object Services created in Kony Fabric Console are displayed in this page.

  3. Click Export (the green arrow) icon to export the data in storage object.
  4. Click Browse to select where you want to save the storage objects data file (.zip) and click OK to continue.
  5. The data will be exported as a zip file in the selected location.

  6. Extract the zip file. You will find a CSV (Comma Separated Values) file at a service level.
  7. Edit the .csv file, and insert the new records. A user can edit and modify more than one .csv file by inserting the new records and updating the existing records.

    The file name the files of .csv files should be as <objectname>.csv.

    For example: Employee and Department are two objects (tables). To update both the tables, modify both employee.csv and department.csv files. Archive the files into a single zip file.

  8. Zip the modified .csv file.

Import Storage Objects Data from .csv to Admin Server Console
  1. In the admin server console, choose Object Services.
  2. Click the Import icon to import the modified data set.
  3. In the Import File box, browse to your storage objects data file, and then double-click to select it.

  4. Click Upload to upload the selected file.
  5. In the Object Services tab, select the storage service imported to get the imported data.
  6. In the Request Input tab, click Get Response.

  7. The Response Output displays the imported data in the form of a source code.

Creating a Salesforce Object Service

Kony Fabric supports Salesforce as an endpoint in object services. The Kony Fabric developer creates a Salesforce object service and defines the data model with the fields required by the mobile app. Upon publishing the Kony Fabric app, a data schema is created in the back end based on the data model and a new self-contained database is instantiated.

A user needs to have a valid Salesforce login to perform any operation. Users can perform the following after the login is authenticated.

How to Create a Salesforce Object Service

To create a Salesforce object service, do the following:

  1. On the Apps page, click Add New.
  2. Click on Edit App Name button to enter a unique name for the app. For example, SampleSalesforceObject.
  3. On the Identity tab, configure a new identity service or use an existing service.
  4. Click the Objects service tab.
  5. Click Configure New.
  6. Click in the Name field, and enter a name for the object service.
  7. Click on the Endpoint Type field. A drop-down menu appears. Click Salesforce.
  8. Under Security Level, use Authenticated App User.
  9. In the Authentication field, you can select the identity provider by selecting the option Use Existing Identity Provider or select specify a Login Endpointoption.
  10. Click the Description field, and enter a description for the object service.
  11. Click Save and Configure.

Create a Data Model for the Storage Service

To create a data model, follow these steps:

  1. Click Configure New.
  2. In the Name text box, enter Object, and then click Save.
  3. In the Configure screen, the name of the object appears in the list of objects.
  4. In the Data Model tab of the navigation pane, under the object, click Fields.

    The fields that Kony Fabric generates by default appear. The fields are populated in the database when you save the object service.

  5. Click the Add button.
  6. In the Name column, click in the field and enter Id.

    The name of a field can be a maximum of 25 characters.

  7. In the Primary Key column, click in the field, and select true from the menu.

    When you set the Primary Key attribute to true for a field, the Unique attribute is automatically set to true.

  8. In the Autogenerated column, click in the field, and select true from the menu.

    When you set the Autogenerated attribute to true for a field, the Type attribute is automatically set to number.

  9. Click the Add button.

    A new row appears in the fields list.

  10. Similarly, enter all the fields and click Save.

  11. Click Mapping.

    If you select an existing identity provider while creating a service, you need to enter your Salesforce credentials to create mapping for the object service.

Configuring Relationships between Objects

Now you can define the relationships between the objects in the data model.

  1. In the Data Model tab of the navigation pane, click Relationshipsunder the Object .
  2. Click the Add button.
  3. Click in the Select Target Objects field. A drop-down menu appears. Select the Object.

    In the Select Relationship Type field, a storage service currently supports only a One to Many relationship.

  4. Under Specify Object Attribute Relationships, click in the Source Object Attributes field. A drop-down menu appears. Select a field.
  5. Click in the Target Object Attributes field. A drop-down menu appears. Select a field, and then click Save.

  6. In the Publish tab, select an environment and publish the app by clicking the Publish button.

Testing the Service in Kony Fabric

After you have published the service, you can test the service from Kony Fabric. Only the published state of the service is tested. Changes that you make in the service designer that are not published cannot be tested.

To test a published service, do the following:

Creating a MongoDB Object Service

With Object Services, you can create an object on Kony Fabric that uses MongoDB for storing data for apps.

MongoDB is a free and open-source cross-platform document-oriented database. Classified as a NoSQL database, MongoDB avoids the traditional table-based relational database structure in favor of JSON-like documents with dynamic schemas (MongoDB calls the format BSON), making the integration of data in certain types of applications easier and faster.

How to Create a MongoDB Object Service

To create a MongoDB object service, do the following:

  1. On the Apps page, click Add New.

  2. Click the Edit App Name button to enter a unique name for the app. For example, SampleMongoDBApp.

  3. Click the Objects service tab.

  4. Click Configure New.

  5. Click in the Name field, and enter a name for the object service. For example, SampleMongoDBObject.

  6. Click in the Endpoint Type field. In the drop-down menu, select MongoDB.

  7. Under Security Level, select Authenticated App Use. If you set the security level to Public, you are not required to enter the user name and password.

  8. Click in the Hostname field. Enter the name of the MongoDB host.

  9. Click in the Port field. Enter the port of the MongoDB.

  10. Click in the Database Name field. Enter the name of the MongoDB database that you are using for the object service.

  11. If you have set up an identity service that validates the authentication of the users before accessing your application, enter the user name and password for the Identity Service.

  12. Optionally, enter the following properties for the MongoDB database: Connections per host (the total number of connections available for connection to the host), Maximum wait time (wait time in microseconds for the lock acquisitions), Connection timeout (the default is never timeout), Socket timeout (the default is never timeout), and Description.

  13. Click Save & Configure.
  14. On the Configure page for the object service, click Generate.

  15. On the Import Objects from Backend screen, select MongoCollection and MongoDocument, and then click Next.

  16. Click Generate.

Test the Methods in the Data Model

  1. Click the Mapping tab in the navigation pane.

  2. Expand the MongoCollection object.

  3. Click Create.

  4. Click the Test tab.

  5. In Request Payload, enter the name of a collection to create. For example, myTestCollection.

  6. Expand the MongoDocument object.
  7. Click Create.
  8. In the Mapping Configuration screen, click Test.
  9. In Request Payload, type the following code to add a record to the collection.
  10. Click Send.

 

Enhanced Identity Filters - Objects

Identity filters are an enhanced data filtering mechanism available in Storage Services and Service-Driven Objects. For Service-Driven Objects, enhanced identity filters are configured on the underline integration/orchestration services. For more details, refer to Enhanced Identity Filters - Integration Services. You can use identity filters to filter data for a mobile app based on dynamic fields returned from an identity provider.

When a user logs on to a mobile app, the logon can invoke a custom Kony Fabric identity service. The response to the back-end logon contains identity or security attributes for the logged on user. For example, a user_id field. The storage service can use the identity or security attributes from the logon response as input parameters for operations, such as get, create and update.

Update a Storage Object from the User Profile

A key advantage of identity filters is the ability to update certain parts of a storage object from the identity service and not the mobile app. With a storage object, the mobile app should not be able to update certain fields or elements of the object. For example, a field that identifies who created a record (CreatedBy) or who updated a record (LastUpdatedBy).

By using an identity filter in a storage service, the userID from the identity profile is mapped to the CreatedBy field as an input parameter. When the mobile app user creates a record, Kony Fabric sets the CreatedBy value from the identity provider and not the mobile app. The mobile app user cannot set the CreatedBy field because the mobile app does not include the CreatedBy field for data entry.

Constrain Data with an Identity Filter that the User Cannot Modify

Another key advantage of using identity filters to query data is that the mobile app user cannot access and modify these filters. For example, an employee that uses the mobile app can view and access only the records that she created, while the manager can access the records that all employees created. Kony Fabric maps a user attribute from the user profile to an input parameter for the storage service query. The mobile app user cannot modify the identity filter because the query was executed on the Kony Fabric storage service and not the mobile app.

Use Case: Auto Dealership Sales Manager

Bill is the sales manager of an auto dealership that sells Steed brand cars. Bill uses a mobile app that is provided by Steed. Bill uses the mobile app to get sales reports, learn about special internal sales programs, and look up invoice prices for his dealership.

The sales manager has a user name that he uses to log on to the account. Steed maintains an internal dealerId in Bill's user profile that identifies the dealership that Bill is associated with. The dealerId is sensitive information and a sales manager is not privy to and cannot see his internal dealerId. All the backend APIs need this dealerID as an input parameter during any subsequent integration queries.

When Bill logs on to the mobile app, the response to the logon from the back end contains Bill's internal dealerId. The Kony Fabric identity service stores this identity attribute for the session. In the storage service, the get operation uses this identity attribute as an input parameter to filter the request for data that is sent to the mobile app. For example, when Bill looks up manufacturer dealer incentives or invoice costs, the storage service adds Bill's dealerId to the query. The query returns only dealer incentives and invoice costs for Bill's dealership. At no point does Kony Fabric send Bill's dealerId to the mobile app. This eliminates the possibility that Bill, or anyone else that gains access to Bill's mobile device, can use the dealerId to access incentives or invoice costs for other dealerships or breach company data.

Use Case: Banking App

The Oakway National Bank (ONB) has a mobile banking app. The mobile app uses a custom SOAP identity service configured on Kony Fabric. When a customer of ONB signs in to the app, the sign-in invokes the identity service. The response to the back-end sign-in contains a user security attribute, for example, CRM_Id.

After the user signs in successfully, every subsequent integration request to the back end must have the CRM_Id as an input parameter to identify the authorized user who is accessing the private bank accounts. A user's CRM_Id is sensitive and is not shared with the user. A hacker could use a CRM_Id to illegally access a user's personal financial information. By using an identity filter with the storage service, the CRM_Id is preserved on Kony Fabric itself and not sent to the user's mobile app. This reduces the possibility of an intruder gaining access to sensitive data on the mobile device.

How to Configure Identity Filters

You configure identity filters on the operations (verbs) of an object in a storage service. For Get operations, you configure identity filters on the Security Filters tab. For the Create, Update, and Delete operations, you configure identity filters on the Request Input Parameters tab. To configure identity filters for a storage service, you must link the storage service to a Kony Fabric identity service.

To link a storage service to an identity service, do the following:

  1. In Kony Fabric, click the Objects service tab.

    2. A list of object services appears. This is the list of object services that have been created for the Kony Fabric app.

  2. Select a storage service.

    3. A storage service is an object service that you have configured to use storage on the Kony Fabric back end. When you create a storage service, you select Storage as the endpoint type.

  3. Click in the Authentication field, and select the identity provider that you want to use.
  4. Click Save.

Configure a Security Filter

To configure a security filter for a Get operation in a storage service, do the following:

  1. In Kony Fabric, click the Objects service tab.

    2. A list of object services appears. This is the list of object services that have been created for the Kony Fabric app.

  2. Select a storage service.
  3. On the Mapping tab of the navigation pane, click the plus button next to an object.

    4. The list of operations, or verbs, for the object appears.

  4. Click the get verb.

    5. The configure screen for the get verb appears.

  5. Click the Add button.
  6. In the Data_Model_Field column, click the drop-down menu, and select a field. For example, LastUpdatedBy.

    7. Select a field from the object that you want to use to filter the data returned by the query.

  7. In the Condition column, click the drop-down menu, and select eq.

    8. The available conditions are eq (equals), gt (greater than), and lt (less than).

  8. In the Value column, click the text box and enter profile.user.id. When you start editing the field, dependent identity services are auto populated. Select the identity service you want.

    9. This maps the user ID attribute from the identity service to the Id field in the storage object.

  9. In the Description column, enter a description of the security filter.

  10. Click Save.

    11. This security filter is added to any get operations performed on the Student object.

The security filter constrains the results of a get operation that are returned to the mobile app. For example, if the mobile app has an option to get a list of student records that the user had recently updated, Kony Fabric adds this security filter to the query. The mobile app retrieves only the student records that were updated by the logged on user. The field that Kony Fabric used to filter the results, LastUpdatedBy, is added to the query only in Kony Fabric and is not sent to mobile app with the results. The mobile app user cannot access this field and use it to retrieve records that were updated by another user.

Configure Identity Filters

To configure identity filters for a create operation in a storage service, do the following:

  1. In the navigation pane, click the Mapping tab, and then click the plus button next to the an object. For example, Teacher.
  2. Click the create verb.

    3. The Request Input Parameters tab appears in the Configure screen. You define how to use the user profile data by selecting a verb and the data model field that you want to map to the user profile data.

  3. Click Add.
  4. In the Data_Model_Field column, click the drop-down menu, and select the CreatedBy attribute.
  5. Click the drop-down menu in the Value column, and select identity.

    6. An identity value indicates that Kony Fabric will retrieve the value specified from the user's security profile in the identity service that is linked to the object service.

  6. In the text box next to the identity value, enter profile.user.id.

    7. This specifies that Kony Fabric will populate the value of the input parameter from the user's security profile.

  7. Click Add.
  8. In the Data_Model_Field column, click the drop-down menu and select the LastUpdatedBy attribute.
  9. Click the drop-down menu in the Value column, and select identity.
  10. In the text box next to the identity value, enter profile.user.id.

  11. Click Save, and then in the navigation pane, click the update operation.
  12. Click Add.
  13. In the Data_Model_Field column, click the drop-down menu in the Data_Model_Field column, and select the LastUpdatedBy attribute.
  14. Click the drop-down menu in the Value column, and select identity.
  15. In the text box next to the identity value, enter profile.user_id.
  16. Click Save.
  17. In the navigation pane, under the Teacher object, click the update operation.
  18. Click Add.
  19. In the Data_Model_Field column, click the drop-down menu, and select the LastUpdatedBy attribute.
  20. Click the drop-down menu in the Value column, and select identity.
  21. In the text box next to the identity value, enter profile.user_id.
  22. Click Save.

    Object services enabled with security filters cannot be tested from Kony Fabric Console.

Preprocessor and Postprocessor References

An identity session is read-only and cannot be modified in the preprocessor and postprocessor, or an integration service. Once the context is accessible, a Kony Fabric developer can refer to the identity session context.

Support Identity Provider Types

The following identity providers are not supported for Storage Services and identity filters:

 

Object Service Mapper

The core mapper engine is integrated into the Object Services pipeline. The mapper is an engine that logically takes in JSON, using the declarative XML that it is passed; modifies the JSON; and creates nodes in the JSON and updates existing nodes.

For the request that is coming in to the mapper, after basic URL parsing and ODATA parsing are performed, all the context is made available to the request mapper. The request mapper modifies the payload and sends it into the next stage of the pipeline, which goes to the back end, typically by using an integration connector.

After the response is picked up, the whole context is made available to the response mapper. The Response mapper makes changes to the data, and outputs the data after some formatting. The internal mapper logic is the same for both the input and output pipelines, but the context that is made available to the mapper changes.

The following diagram shows the Object Services pipeline:

Request Mapper

On the input, when the mapper is applied, it is equivalent to the following:

mapper("input mapper xml", $current_input = data)

The $data is logically a blob with all the context made available to the mapper. You are passing in transformational XML to run on the current input. The mapper input can access any of the data that is passed to it.

request_in : Read-only, input payload JSON from API request.

request_out : Read-write, (a copy of input payload), transformed JSON that is sent to next stage.

vars : Empty. This is referenced using $vars and is used by mapper XML as a global variable store

Response Mapper

On the output, when the mapper is applied, it is equivalent to the following:

mapper("output mapper xml", $current_input = data)

The $data is logically a blob with all the context made available to the mapper.

response_in : Response from back end logically represented as JSON.

response_out : Transformed JSON using the XML mapper sent in the "records" field of the API response.

vars : Empty. This is referenced using $vars and is used by mapper XML as a global variable store.

Mapper Elements

The mapper includes the following built-in variables, built-in functions, and blocks.

Built-in Variables

 a/b/c   /* An input path of a.b.c in the given object */

        
 ../b      /* inputpath = "b" on $current-input.getParent() */

        
 

        
 $current-input /* Input instance of current map block */

        
 $current-output /* Output instance of current map block */

        
 $mapper-input /* Mapper instance’s global input */

        
 $mapper-output  /* Mapper instance’s global output */

        
 

        
 $vars/x /* Variables are stored in this hash.  All variables are GLOBAL */

        
 

        
 $args/<arg name> /* Arguments passed to a function */

        
On a function call, by default, $args.current-input is set to $current-input, and $args.current-output is set to $current-output.

        
 

        
input="myinput" inputpath="firstname" is equivalent to $myinput["firstname"]
        

        
inputpath="firstname" is equivalent to $current-input["firstname"]

        
Input="3" /* not starting with a $, it is constant value. To use $ as a constant, use the escape character, for example, "\$".*/
        

        
output="$myoutput" outputpath="lastname" is equivalent to $myoutput["lastname"]

        
Built-in functions

        
The Kony namespace contains a number of built-in functions that you can use with the mapper. The built-in functions are: 

        
    
            
  • equal
    • 
            
  • concat
    • 
            
  • substringBefore
    • 
            
  • substringAfter
    • 
            
  • choose-when-otherwise
    • 
            
  • random
    • 
            
  • min
    • 
            
  • max
    • 
            
  • sum
    • 
        

        
 The kony namespace is reserved for Kony-defined functions only.  User-defined functions cannot use the kony namespace.

        
Blocks

        
The following table describes the blocks available:
        

        

            
            
            
            
                

                    Block
                    Description
                    Example
                

            
            
                

                    map
                    
                    This is the main block in mapper.  
                    
                        
 <map inputpath="x/y/z" input="$current-input"

                        

            outputpath="x" output="$current-output">

                        
 
</map>


                    

                

                

                    set-param
                    
                    Sets an output parameter from input.  

                    
                        
 <set-param 


                        
inputpath="x/y/z" input="$current-input"

                        
outputpath="x" output="$current-output"  />

                        
 Output.outputpath=input.inputpath

                    

                

                

                    set-arg
                    
                    Variant of set-param to set the argument of a function.
                    
                        
 <set-arg 
          

                        
name="x"

                        

          inputpath="x/y/z" input="$current-input"

                        
  
/>

                        
is a shortcut for the following:

                        
 
<set-param 

                        

           inputpath="x/y/z" input="$current-input"
           

                        
outputpath="x" output="$args"  />


                    

                

                

                    set-variable
                    
                    Variant of set-param to define and set a global variable.
                    
                        
 <set-variable 
          

                        
name="x"

                        

          inputpath="x/y/z" input="$current-input"

                        
  
/>

                        
is a shortcut for the following:

                        
 
<set-param 

                        

           inputpath="x/y/z" input="$current-input"
           

                        
outputpath="x" output="$vars"  />

                    

                

                

                     
                     
                     
                

                

                    exec-function
                    
                        
Execute function.

                        
The return value of exec-function is written to the output/outputpath attributes of exec-function.

                    		
                    
                        
 <map inputpath="contact" outputpath="contact">      

                        
<exec-function name="contact-field-map" >
                

                        
/* input is set to $current-input and
                     output is set to  $current-output by default */
      

                        
</exec-function>/
 

                        
 </map>


                        
 /* Complex */


                        
 <map inputpath="contact" outputpath="contact" output="$current-output" >
    

                        
<exec-function name="field-map" outputpath="myresult" output="$vars">
          

                        
<set-arg name="a" inputpath="firstname" input="$current-input" >
          

                        
<set-arg name="b" input="3" >
     

                        
</exec-function>
 

                        
 </map>


                        
 $vars[myresult] = field-map({a: "$current-input" ["firstname"], b: "3" })


                    

                

                

                    choose-when-otherwise
                    
                    When a "test" condition evaluates to true, then the "when" block is executed. If the "test" condition evaluates to false the "otherwise" block is executed.
                    
                        
 <choose>

                        
                <when test="$vars/NTFCondition">

                        
...

                        

                </when>

                        

               <when test="$vars/CONCondition">

                        
...

                        

                </when>


                        
                <otherwise>

                        

                     ...

                        
                 </otherwise>

                        
 
</choose> 


                    

                

                

                    Create-lookup 
                    
                    Create-lookup loops on the inputpath array and creates a hashmap with a lookup-key parameter as key and value as “Node” object refers to corresponding customer row of the input object.
                    
 <create-lookup inputpath=”Customers” output=”$vars” ouputpath=”customerMap”>
		<lookup-key inputpath=”Id”/>
	</create-lookup>


                    		
                

                

                    Lookup 
                    
                    Retrieves the “Node” object from the hashmap and makes it available in the output.
                    
 <lookup input=”$vars” inputpath=”customerMap” outputpath=”customerRef” output=”$vars”>
			<lookup-key inputpath=”CustomerId”/>
		</lookup>


                    		
                

                

                    Create-group 
                    
                    Create-group generates an aggregate group of objects based on a key designated by the group-key block. Each object is contains multiple entries. Each entry is a key/value pair.
                    
 <create-group inputpath=”Time_Entry” output=”$vars” ouputpath=”customerMap”>		<group-key inputpath=”Timesheet_Id”/>
							</create-group>
						

                    		
                

                

                    Group-key
                    
                    Key used to group items for aggregation.
                    
 <group-key inputpath=”Timesheet_Id”/>
							
						

                    		
                

                

                    
                        
javascript  

                    		
                    
                        
JavaScript element must occur one time only as a child element to the Function element.


                        
Then name of outputpath attribute represents a field in the app data model.


                    		
                    
 <function name="NameConcat">
		<javascript outputpath="FullName">
			<set-arg name="firstName" inputpath="FirstName" />
			<set-arg name="middleName" inputpath="MiddleName" />
			<set-arg name="lastName" inputpath="LastName" />
			
<script>
			You logic goes here.....


			</script>
		</javascript>
	</function>

                    		
                

                

                    script
                     The Script element is a required child element in a JavaScript element. It must occur one time only.
The JavaScript snippet should be written in CDATA section of this element.
                    
 
			<script>
			<![CDATA[
			  function concat(){
			   var result = firstName+’ ‘+ middleName + ’ ‘+lastName.substring(0, 1).toUpperCase() + '. '
			    return result;
  			    }
			   concat();
			 ]]>
			</script>


                    		
                

            
        

        
 

        
Example: Mapper Structure

        
The following example shows the structure of the mapper in declarative XML.

        
 <mapper xmlns="http://www.kony.com/ns/mapper">  /* root element */

        
<function name="field-map-a2b"> /* Function definitions */

        
<set-param />

        
<map input= output= inputpath= outputpath=></map>

        
</function>

        
<map input= output= inputpath= outputpath=> /* Mapper blocks */

        
<set-param input= inputpath= output= outputpath = />

        
<set-variable input= inputpath= output= outputpath=  />

        
<exec-function name="field-map-a2b">

        
<set-arg />

        
</exec-function>

        
</map>

        
<map> </map>  /* another map node */

        
 </mapper>

        
 

        
Example: Simple Mapping 

        
In this simple mapping example, the input is a list of records under A, and each record has P1 and P2 fields that we want to output to the API response by transforming P1 to Q1 and P2 to Q2. 

        
The back end is returning columns by the name P1 and P2, where the object on the client side has fields named Q1 and Q2. For example, the backend could be returning FName and LName, and these are mapped to fields with more friendly names on the client side, Firstname and Lastname. The mapper, in each of the records it gets, picks up the value of P1, put it into a key of Q1 in the output. 

        
The mapper is output-driven, so in the output, choose a path with the name A (outputpath="A"), and set up a parameter Q1 in output (set-param outputpath="Q1" inputpath="P1"), by taking the value from P1 from the input from a path with the name A (inputpath="A").

        
Input

        
 {

        
"A": [

        
{

        
 "P1": "value1",

        
 "P2": "value2"

        
}

        
]

        
 }

        
Output

        
 {

        
"A": [

        
{

        
 "Q1": "value1",

        
 "Q2": "value2"

        
}

        
]

        
 }

        
Mapping

        
 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

        
 <mapper xmlns="http://www.kony.com/ns/mapper">

        
<map outputpath="A" inputpath="A">

        
<set-param outputpath="Q1" inputpath="P1" />

        
<set-param outputpath="Q2" inputpath="P2" />

        
</map>

        
 </mapper>

        
 

        
Identity Support in Mapper

        
The mapper can access identity security or profile attributes if they are needed by your service. For example your service requires an input parameter that is available from the identity profile attribute.

        
To use identity support follow these guidelines:

        
    
            
  • The inputpath should be defined in the format “identity/<IdentityProviderName>/<Security_Or_Profile>/<token name> “
    • 
            
  • In the definied structure, you must select either security or profile, depending upon the specific identity token type that you want.
    • 
            
  • Input should be defined as “$mapper-input”, which points to the mapper input node.
    • 
        

        
Example: Acccessing the Identity Profile Attribute

        
The following example shows how to access the identity profile attribute using the mapper. The example is a request mapper that retrieves the value for the “PRODUCT” parameter from the “user_id” token of the “SAPIdentity” identity provider.

        
 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

        
 <mapper xmlns="http://www.kony.com/ns/mapper">

        
 <map inputpath="request_in" outputpath="request_out">

        
 <set-param inputpath="identity/SAPIdentity/profile/user_id" input="$mapper-input"    outputpath = "PRODUCT "/>

        
 </map>

        
 </mapper>

        
 

        
Example: Accessing the Identity Security Attribute

        
The following example shows how to access the identity security attribute using the mapper. In this example, an identity security attribute value is mapped to a result parameter named "SAP-Session-Key-Value".

        
 <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

        
 <mapper xmlns="http://www.kony.com/ns/mapper">

        
 <map inputpath="response_in" outputpath="response_out">

        
 <map inputpath="Sample_Object" outputpath="Sample_Object">

        
 <set-param inputpath="identity/SAPIdentity/security/KonySAP-Session-Key" input="$mapper-input" outputpath="SAP-Session-Key-Value"/>

        
 </map>

        
 </map>

        
 </mapper>

        
 

        
Visual  Object Mapper

        
Kony Fabric Object Services includes a visual designer that lets you add, modify, and delete request and response mappings of any of your object services using a drag-and-drop interface. 

        

            
        

        
The backend object, data model, and the other objects and functions that are associated with the service are each displayed in their own container. Each container has one or more items listed within it. Each item within a container has a triangle next to it that you can click and drag to another item in another container to create new mappings.

        
Each mapping has a corresponding color associated with it.

        
    
            
  • Green corresponds to a valid mapping.
    • 
            
  • Red corresponds to an invalid mapping (for example, the data types do not match).
    • 
            
  • Blue corresponds to a common mapping.
    • 
        

        
The design view is available along with a XML code view of your mappings. You can quickly switch between code view and the visual design view by clicking on the appropriate tab in the viewing pane.

        
The procedures in this section describe how to use the visual designer to manage your Object Service mappings.

        
How to View and Edit Mappings

        
You can examine any object service in visual design view that has request and response mappings. This section describes how to access visual design view for your services.

        
The default visual design view pane is view-only and cannot be edited. 

        
After you are in visual design view, you can increase and decrease the zoom level of the viewing pane by clicking the + and - buttons in the upper-left corner of the pane. In addition, you can hide mappings  by clicking the button below the zoom buttons and selecting which type of mappings you want to hide.

        
You can also edit your mappings by clicking the Edit button at the bottom of the viewing pane.  

        
To access visual design view for a specific object service, do the following:
        

        
    
            
  1. In the Object Services list, click the ... button on the right side of the service listing you want to view, and then click Edit Configuration.
    2. 
            
  2. In the navigation pane, click the Mapping tab.
    3. 
            
  3. In the Mapping tab, click the item you want to view.
    4. 
            
  4. Click either the Request Mapping or the Response Mapping tab.
    5. 
            
  5. Under Request Mapping or Response Mapping, click the design view tab, which is located next to the code view (</>) tab.
    6. 
            
  6. If you want to edit your mappings for this service, click the Edit button in the lower-right corner of the page.
    7. 
        

        
How to Add Mappings

        
You can map objects to each other using your mouse to click on one item and then dragging to another item.

        

            
        

        
Depending on the type of item, the item can have multiple mappings from several different sources.

        
To map one item to another, do the following:

        
    
            
  1. Click and hold on the triangle next to the item you want to connect.
    2. 
            
  2. While continuing to hold the mouse button, move your mouse cursor to the triangle next to the item you want to connect to and release the mouse button.
    3. 
        

        
If you attempt to map items of differing data types, an error message will appear.

        
How to Add Data Models

        
You can add other data models to your existing service, which you can then map to the existing functions and objects. Each data model that you add will appear as a collapsible list in the container you added the data model to.

        
To add a new data model, do the following:

        
    
            
  1. Click on the container where you want to add the data models, and click the edit icon at the top right of the container.
    2. 
            
  2. In the Edit drop-down menu, select the check box next to each data model that you want to add.
    3. 
            
  3. Click Confirm.
    4. 
        

        
How to Hide Mappings

        
Some of your services might include a large number of mappings that can clutter the visual design view. You can temporarily hide these mappings to make it easier to create additional mappings, and then show the mappings again after your changes are complete.

        
To hide and show mapping to an item, do the following:

        
    
            
  1. Right-click the item that you want to hide mappings from and click Hide Mapping.
    2. 
            
  2. If you want to show the mappings, right-click the item again and select Unhide Mapping.
    3. 
        

        
How to Edit or Delete Items and Containers

        
You can right-click on each container or item to view a context-sensitive menu that you can access. The menu contains actions that you can perform on the item. These actions include 

        
    
            
  • Move Up - Moves the item up in the container list.
    • 
            
  • Move Down - Moves the item down in the container list.
    • 
            
  • Delete - Deletes the item.
    • 
            
  • Delete Connection - Removes the mapping between items.
    • 
        

        
Containers also have an edit icon that you can click to edit the container.

        

            
        

        
 

        
If you want to view the properties of an item, hover your cursor over the icon next to the item.

        

            
        

        
How to Use Automap

        
You can automatically map items that have the same field names with each other by using the Automap button in the visual designer.

        
To use Automap, do the following:

        
    
            
  1. Click the Automap button at the top of the design view.
    2. 
            
  2. Click Map to map the matching fields together
    3. 
        

        
How to Remove Common Mappings

        
You can apply or remove common mappings in your service by clicking the Common Mappings button.

        

            
        

        
Then select either Apply or Remove from the drop-down menu.

        
How to Add Constants and Variables

        
You can add new constants or variables to your service, which you can then map to other items in your service.

        

            
        

        
To add a constant, do the following:

        
    
            
  1. Click Insert Constant.
    2. 
            
  2. Click on the container that was created and type the value for your constant.
    3. 
        

        
To add a variable, do the following:
        

        
    
            
  1. Click Insert Variable.
    2. 
            
  2. Click in the Name field of the variable container and type the name of your variable.
    3. 
        

        
How-to Use Functions in the Visual Designer

        
When the visual designer is in Edit mode a list of functions appears on the left side of the view. 

        

            
        

        
The list includes all built-in mapper functions, as well as any custom functions you have created. 

        
You can add new functions to your service by dragging and dropping the function from the list. You can also add, edit, import, export, and delete any custom functions you have.

        
To add a built-in function, do the following:

        
    
            
  1. Select the function you want to use from the function list
    2. 
            
  2. Click and hold the mouse button on the function.
    3. 
            
  3. While continuing to hold the mouse button, move your mouse cursor to the location you want to place the function  and release the mouse button.
    4. 
        

        
 

        
How to Use Custom Functions in Visual Designer

        
You can use any custom functions that you have created for this service by using the same procedure for adding a built-in function described in the previous section. In addition, you can take the following actions:

        
    
            
  • Add a new custom function
    • 
            
  • Edit an existing function
    • 
            
  • Import a custom function
    • 
            
  • Export a custom function
    • 
            
  • Delete a custom function
    • 
        

        
The following procedures describes each of these actions.

        
To Add a new custom function, do the following:
        

        
    
            
  1. In the Custom Functions section of the function list, click Add.
    2. 
            
  2. In the Create New Custom Function window, click the Custom Function Name field and type the name you want for your function.
    3. 
            
  3. In Function Type, select either XML or JavaScript.
    4. 
            
  4. In the Input section, select either of the following:
    • Defined Parameter Set- Creates a static list of input parameters for this function. For each parameter that you want to add, do the following
      1. Click the Add button.
      2. In the Name field, type the name you want for this parameter.
      3. In the Type field, click the drop-down menu and select the data type.
      4. If you want the parameter to be mandatory, select the Mandatory check box.
    • Dynamic Number of Parameters - Creates a variable list of input parameters. For dynamic parameters, do the following:
      1. Click the Add button.
      2. In the Name field, type the name you want for this parameter.
      3. In the Type field, click the drop-down menu and select the data type.
      4. In the Min and Max fields, type the minimum and maximum number of input parameters for this function.
    5. 
            
  5. In the Output section for each parameter you want to add, do the following:
    1. Click the Add button.
    2. In the Name field, type the name you want for this parameter.
    3. In the Type field, click the drop-down menu and select the data type.
    4. If you want the parameter to be mandatory, select the Mandatory check box.
    6. 
            
  6. In the Code section, add any custom code you would like corresponding to the function type you selected (XML or JavaScript).
    7. 
            
  7. Click Save and Insert to add the function to your custom function list and to add the function into your mappings.
    8. 
        

        
If you do not want to immediately add the function to your mappings, click the Save button.

        
To edit an existing function, do the following:
        

        
    
            
  1. Click the Edit icon next to the custom function.
    2. 
            
  2. Make any desired changes, and then click Save.
    3. 
        

        
If you want to edit a custom function in mapping area, click on the Edit icon on the function's container.

        
To import a custom function, do the following:
        

        
    
            
  1. In the Custom Functions section of the function list, click the Import button.
    2. 
            
  2. In the Import Functions window, in the From File section, drag-and-drop and files that you want to add, or click Browse to select files from your network.
    3. 
            
  3. In the From Existing Object Services section, select the check box next to any functions you want.
    4. 
            
  4. Click Import.
    5. 
        

        
To export a custom function, do the following:
        

        
    
            
  1. In the Custom Functions section of the function list, click the Export button.
    2. 
            
  2. Select the check box next to any function that you want to export, and then click Export.
    3. 
        

        
To delete a custom function, do the following:
        

        
    
            
  1. Click the Delete icon next to the custom function.
    2. 
            
  2. In the confirmation pop-up, click Delete.
    3. 
        

        
How to Use Actions on an Object Service

        
To use actions for existing services such as edit, clone, clone app data model, unlink, delete, console access control, export, and validate, hover your cursor over the required service, click the Settings button to display the context menu. You can perform the following actions on an existing service:

        
    
            
  • Edit: Allows you to edit a service. After you edit a service, you have to republish all the apps that are using the service to apply the changes.
    To know more about publishing an app, refer to Publish an app.
    If a  service is  part of a published app, you can rename that service only after the app is unpublished. Refer to Unpublish an App.
    • 
            
  • Clone: Allows you to duplicate an existing service. Changes made to a cloned service will not impact the original service.
    • 
            
  • Clone App Data Model: Allows you to duplicate only data model of an existing object service. This option will not duplicate the verbs. Changes made to a cloned app data model service will not impact the original service. 
    • 
            
  • Unlink: Allows you remove the service from the Objects tab of an app. When a service is unlinked, it is disassociated from a particular app.
    If you want to use an unlinked service, select the service from the Use Existing Integration Service dialog.
    • 
            
  • Delete: Allows you to delete a service.
    If a service is a part of a published app, you can delete that service only after you unlink the service from all the published app.
    • 
            
  • 
                
    Console Access Control: Controls the access to the applications and services of apps.
    
            
    • 
            
  • Export: Allows you to export the object service into your local system. The exported file is an .xml file.
    • 
            
  • Validate: Allows you to validate the object service.
    •