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.
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.
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.
You must ensure that any values that you change do not impact the behavior of the pattern instance.
Back to the Worklight: resource handler pattern specification