Tasks to complete after generating the Worklight: resource handler pattern

Tasks that you must complete after you have generated the pattern.

The pattern creates a subflow for each operation (Create, Read, Update and Delete). Complete the implementation of the subflows with calls to your back end applications. The pattern generates a reference implementation for each CRUD operation in the subflows. The reference implementation is provided as an example. You can use the implementation to deploy the generated application to Message Broker as a working solution, and helps you to understand how the pattern works.

The Worklight adapter generated by this pattern passes the data from the mobile application to Message Broker with no transformation. This design means that you must agree the format of the JSON data passed between the mobile application and the subflows in Message Broker. The application data that is passed between the mobile application and Message Broker is a single JSON object. The mobile application provides this JSON object when it invokes WL.Client.InvokeProcedure to call a back end application.

You can test the Message Broker application separately from Worklight and the mobile application. For example, the FireFox Poster plug-in can send and receive HTTP/JSON requests to Message Broker. You can also test the Message Broker application through Worklight Studio. Worklight Studio can invoke the adapter generated by this pattern by simulating the HTTP/JSON request from a mobile application.

If you enabled security, the mobile application must also provide the user credentials for authentication and authorization.

Security

If you enabled security, the pattern generates additional configurable service files. The files configure the security processing in Message Broker. The first file (AuthenticationSecurityProfile.configurableservice) configures the authentication performed by the HTTPInput node. The second file (AuthorisationSecurityProfileReaders.configurableservice) configures the authorization for readers. The third file (AuthorisationSecurityProfileWriters.configurableservice) is only generated if you selected one or more write operations (Create, Update or Delete). This file configures the authorization for writers.

Deploy the configurable service files to Message Broker in the Message Broker Toolkit or in Message Broker Explorer. For more information see the Configurable services topic available in the Message Broker help.

At deployment time, it is recommended to set an LDAP user ID and password using mqsisetdbparms. Message Broker will use these credentials to login into the LDAP server to perform authentication. If a user ID and password are not configured, Message Broker will bind to the LDAP server anonymously. For more information, see the Configuring authentication with LDAP topic available in the Message Broker help.

Global Cache

If you enabled caching, you must configure the global cache in Message Broker. You can configure the default global cache in Message Broker Explorer. For more information, see the Managing the global cache topic available in the Message Broker help.

The global cache does not have automatic expiration (eviction) of data. The application generated by this pattern therefore caches data indefinitely. This may not be sufficient if changes are made to the back end application through other channels (for example, direct to the back end application and not through Message Broker).

There are several ways to refine the caching provided by this pattern. The first option is to check the back end application for changes and to use those events as a trigger to remove entries from the cache. The DatabaseInput can be used to do this. The DatabaseInput node can monitor one or more database tables, checking for changes to the application data. When a change is detected, a message flow can remove the required entry from the cache. The next read request that arrives from a mobile application will not find the data in the cache and will query the back end application to pick up the changes.

A second option is to periodically clear the entire cache. This has the advantage that it is straightforward to implement using the mqsicacheadmin command. A shell script that periodically runs this command with the -c clearGrid option removes all entries from the cache. This approach ensures the cache does not grow indefinitely and it also ensures a maximum time for any data in the cache. For more information, see the mqsicacheadmin topic available in the Message Broker information center.

Message Broker Deployment

  1. Deploy the service to WebSphere Message Broker. The application must be added to a broker archive file.
    1. Click File > New > BAR file.
    2. Enter the name of your application or select one from the displayed list. The list is filtered to show only projects in the active working set.
    3. Enter a name for the BAR file that you are creating.
    4. Click Finish. A file with a .bar extension is created and is displayed in the Navigator view, under the Broker Archives folder. The Content editor for the BAR file opens.
    5. On the Prepare tab, select the generated message flow file to add it to your BAR file.
    6. Click Build and Save to create your BAR file.
  2. Configure the broker archive file. Further configuration of the application in the broker archive file is not required before you deploy the message flows for your Worklight: resource handler pattern instance, but you might want to review some of the default options and configure changes for your environment. In the Manage page of the Broker Archive editor:
    1. Optional: Use the LoggingOn user-defined property to select whether logging is on or off for the web service message flow.
    2. Optional: Use the ErrorLoggingOn user-defined property to select whether error messages are generated.
    3. Optional: You can change any of the configurable properties in the broker archive, for example, properties for security or creating additional instances.

      You must ensure that any values that you change do not impact the behavior of the pattern instance.

  3. Create queues. WebSphere MQ queues must be created if they do not already exist for the error and log messages.
    1. Create WebSphere MQ resources. You can create WebSphere MQ resources either on the command line by using programs and utilities such as runmqsc, or by using the WebSphere MQ Explorer graphical interface. For more information about creating WebSphere MQ resources, see WebSphere MQ Intercommunication, available on the WebSphere MQ library web page.
  4. Deploy the BAR file to an execution group.

Worklight Deployment

  1. Deploy the generated Worklight adapter to the Worklight Server.
    1. Export the Worklight project to the file system from your workspace.
    2. Start Worklight Studio and import the Worklight project.
    3. Click on the adapter in the imported project and click Run As > Deploy Worklight Adapter.

Back to the Worklight: resource handler pattern specification