Creating a Custom Module

You can extend the functionality of the Livelink Workflow module by adding task types, data types, workflow types, or event trigger scripts that perform customized operations. To do so, you must first create a custom module that stores the new functionality you are adding.

Always store the custom functionality that you create in a module that can be installed and uninstalled separately from all other Livelink modules. If you modify an original Livelink module, future updates to the module will automatically overwrite your changes.

In this chapter, you learn how to:

• Create the module's directory structure
• Create an OSpace
• Create a Configure request handler and request handler group for the module

You begin setting up a module by creating the module's directory structure in the staging directory of your primary Livelink installation (for example, c:/opentext/staging).

To create the module directory structure:

1. Create a new directory in the staging directory of your primary Livelink installation, and name it modulename_1_0_0.
The module name is followed by the major version number, the minor version number, and the revision number, respectively.
2. In the modulename_1_0_0 directory, create three new directories and name them html, ospace, and support.

3. If you are going to include HTML help files with your module, create a directory named help in your modulename_1_0_0 directory.

After you create the directory structure for your custom module, you create the OSpace to contain the functionality of the module. All OSpaces have the .oll file extension.

To create the Custom Module's OSpace:

1. In the Livelink Builder, click New OSpace on the OSpace menu.
2. Name the OSpace modulename.oll, and save it in your custom module's ospace directory (for example, c:/opentext/staging/modulename_1_0_0/ospace).

Each Livelink module contains a WebModule object which stores the configuration information for the module. The WebModule object defines the name of the module as it appears on the Livelink administration pages, the internal name of the module, the OSpaces contained in the module, the major version number, minor version number, build level, and revision number of the module, the module's dependencies, and the script that is necessary to create a .ini file for the module.

1. Orphan WebDsp:WebModule in the OSpace of your custom module, and name it modulenameWebModule.
2. In the modulenameWebModule object, set the value of the fEnabled feature to TRUE.
   When set to TRUE, this feature allows Livelink to register the modulenameWebModule object in Kernel:KernelRoot:SubSystem:ModuleSubSystem.

3. Set the value of the fName feature to "Module Name". This feature contains the name that is displayed on the Livelink Intranet Administration page when a Livelink Administrator installs, upgrades, or uninstalls your custom module.

4. Set the value of the fModuleName feature to modulename. This feature stores the internal name for your module. The value must be in lowercase letters and must match the name you used when you created your module directory structure.

5. Set the value of the fOSpaces feature to {'modulename'}. This feature lists the OSpaces that are contained in your custom module.

6. Set the value of the fVersion feature to {'1','0','d','0'}. This feature specifies the major version number, minor version number, build level (b for beta, r for revision, and d for development), and revision number of your custom module. The major version number, minor version number, and revision number must match those you used when you created the module's directory structure. The build level is for your personal reference only.

7. In the modulename Globals object, run the BuildOSpace() script.

The Configure request handler object is used to install, uninstall, and upgrade your custom module. This object defines the name of your module, the schema modifications required by your module, and the custom setup steps that your module needs to perform.

1. Orphan WebAdmin:AdminRequestHandler:Configure in the custom module's OSpace, and name it Configure.

2. In the Configure object, set the fEnabled feature to TRUE.

3. Set the value of the fFuncPrefix feature to modulename.

After you orphan the Configure request handler, you set up the query string that calls the request handler during installation. Next, you create the module.ini file, which is required to install, upgrade, and uninstall the custom module.

1. In the modulenameWebModule object, set the value of the fSetUpQueryString feature to func=modulename.configure&module=modulename&nextUrl=%1.

2. In the modulename Globals object, run the BuildOSpace() script.

3. In the modulenameWebModule object, run the 0DumpModuleConfigToFile() script and save the modulename.ini file in the modulename_1_0_0 directory (the root of your module's directory structure).

The RequestHandlerGroup object keeps track of all the request handlers in your custom module's OSpace. This allows the Configure request handler object that you just created to be registered in the RequestHandlerSubsystem.

1. Orphan WebDSP:WebDspRoot:RequestHandlerGroup in your custom module's OSpace, and name it modulename RequestHandlerGroup.

2. In the modulename RequestHandlerGroup object, set the fEnabled feature to TRUE.

3. Run the SetRequestHandlers() script.

4. In the modulename Globals object, run the BuildOSpace() script.

5. Save and export the custom module's OSpace, and then exit Livelink Builder. You can now start your Livelink Intranet service and install your custom module in Livelink. For more information about installing modules, see the Livelink Installation Guide.

Tip:

You can set the value of the changeStateOspaces variable in the WebBuilder.lxe file to MODULENAME (all uppercase letters), to open the custom module's OSpace in an unlocked state in the Livelink Builder. The WebBuilder.lxe file is stored in the main directory of your primary Livelink installation (for example, c:/opentext).

Now that you have set up the custom module, installed it, and prepared it for use in Livelink, you can begin to create the functionality required to add a new task type, data type, workflow type, or callback event trigger script to a Livelink workflow.

The following sections describe how to complete the custom module:

• Adding New Step Types describes how to add a new type of task to your module. In that section, you add a task type that lets the creators of workflow maps customize the interface that is presented to workflow participants and the operations that occur when the workflow participant works on the task in Livelink.
• Adding New Data Types describes how to add new types of data to your module. In that section, you add a data type that creates a series of workflow attributes and arranges them on custom tabs available to workflow participants when they work on the corresponding tasks.
• Adding New Workflow Types describes how to add new types of workflows to your module. In that section, you create a custom workflow type that appends a date stamp to the title of the workflow when it is initiated in Livelink. This workflow type also runs a callback script when it is initiated.
• Adding Event Trigger Scripts describes how to add event trigger scripts to your module. In that section, you create three event trigger scripts that perform different functions when different workflow events occur.

Each of these sections provides you with general information for incorporating new workflow functionality. This general information is complemented by a specific example of how to apply the functionality, with references to included code samples.