+

Search Tips   |   Advanced Search

Plan to install IBM Worklight


Run a hybrid application in a portal page

When our hybrid application runs with the HCL WebSphere Portal pages rendered in a native application, HCL WebSphere Portal loads the appropriate native resources for the device. These resources are loaded automatically through modules provided in HCL WebSphere Portal. It starts with the wp_worklight_ext module, which is listed in some of the default profiles, including...

To access appropriate native resources for the device on a particular page of the HCL WebSphere Portal, use a profile that includes the wp_worklight_ext module. The default profile, profile_deferred.json, includes wp_worklight_ext, so the appropriate native resources are available to the HCL WebSphere Portal pages by default.
wp_worklight is a version-independent meta-module defined by the worklight61.json file in the theme's contributions folder. This module is a prerequisite of the default Worklight resources that enable access to native features. It also includes the overrides that enhance performance and allow the API libraries to work within the module framework.

The version-dependent platform modules included by the module framework are wl_ios_61 and wl_android_61. These platform modules are defined by the plugin.xml file in the folder...

    PORTAL_HOME\theme\wp.theme.worklight.ext\installedApps\wp.theme.worklight.ext.ear\wp.theme.worklight.ext.war\WEB-INF

These platform modules load the appropriate native resources for the device, giving access to the full Worklight and Cordova APIs. For example, it gives access to the following resources on the device:

  • camera
  • geolocation
  • contacts
  • local storage
  • media
  • push notifications
  • user information

These platform modules are loaded based on device class conditions. For example, in the plugin.xml file for the wl_android_61 module we see... 

<module >
    <runtimeActivation>
        <condition deviceClass="worklight+android"/>
    </runtimeActivation>

The wl_android_61 module loads if the device class is both Worklight and Android. The device class is determined by the HCL WebSphere Portal server based on the user agent string of the client device. For example, a user agent string for an Android phone...

    Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; GT-I9300 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

A Worklight hybrid application automatically appends "/Worklight/version" to the end of the user agent string, such as:

    Mozilla/5.0 (Linux; U; Android 4.0.4; en-gb; GT-I9300 Build/IMM76D) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30/Worklight/6.1.0.0

Matching is used to determine the device classes from the user agent string. The device classes in turn determine the appropriate platform modules to load. For example, the wl_android_61 native resources get loaded for a portal that runs in a Worklight hybrid application on an Android device. But it does not load in many other cases. For example, if it is on an iOS device, or if it is just a portal not wrapped in a Worklight hybrid application, these resources do not load.

The same portal pages adapt their capability automatically based on the context in which they are running. For example, a page can provide access to the device's camera if it runs in the context of a Worklight hybrid application. The same page cannot get access while it is running outside the context of a Worklight hybrid application.

The Cordova and Worklight API have overrides to improve performance and allow integration with HCL WebSphere Portal. The overrides allow the Worklight Client API to find the resources in the deployed web application. The overrides also allow the Cordova plug-ins to be packaged into a module and allow the multiple JavaScript resources to be fetched in one request by the resource aggregation framework.


Shell application

If the application is a shell that uses a web view to render all markup from the HCL WebSphere Portal site, then we do not need a Worklight server.

If the application is using a mixed model approach where some of the application markup is coming from the HCL WebSphere Portal and other markup of the application is coming from native resources that might be fetching Web Content Manager resources, then install a Worklight server to provide these resources.


Direct update service

To use the direct update service feature to update the embedded markup for changes, requires a Worklight server.


Native notifications

If the application uses native notifications, Worklight is required to generate the iOS and Android notification service.


Authentication services

For the Worklight authentication or access control service for single sign-on (SSO) between Worklight and HCL WebSphere Portal, install a Worklight server. To use anonymous access or access all resources of the application through HCL WebSphere Portal or Web Content Manager, then we do not need a Worklight server.


Tracking usage

If the application uses Worklight to track usage, install a Worklight server. The server installed must also support the load from clients who send usage data.


Device provisioning

If we are providing device provisioning, install a Worklight server to provide the certificate for the device and data.


Application Center EAR

The Application Center Ear is an optional application that provides an application store environment. If we are using it to manage applications on devices as an MDM solution, we need a Worklight server to run the Worklight EAR and the Application Center EAR.


Parent Integrate with IBM Worklight