Custom modules in your application can be used to add extra custom metadata and services into your application. You may add any of the following services to your application:
.task
file) to register a new task plan. These task plans may refer to specific schema file. In such a scenario, those schema files must also be deployed and present in the application..handler
file) to configure default Worklist listeners (reporting, email, MessageBroker, control). .assign
file) to configure and register custom assignment handlers..listener
file) to configure and register custom task event listeners..email
file) to calculate the e-mail address of the recipients of an e-mail notification and send it dynamically at runtime. .taskurl
file) to calculate the URL required to navigate directly to the task UI for the task..history
file) to retrieve task history of the task associated with this provider.
Any application can have task plans installed into it to become a task plan host application. Task plans are defined as .task
files within a task plan host application. However, in order to get these task plans registered into a task plan registry so that they can be used, you must first install them into a task plan host application, and deploy that task plan host application to a WebLogic Server instance.
The Workshop for WebLogic plugin for Worklist handles installing .task
files in your application for you. So, when you create a task plan in Workshop for WebLogic IDE, it is automatically installed in your host application. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing task plans into a host application. Both these utilities require the following arguments:
.task
files to be deployed.
This directory may exist either inside or outside the application directory. If it is outside, the .task
files are copied to a location within the application directory that matches the location of the source .task
file relative to the specified task plan source directory. If the source directory is inside the application directory, no file copying is done.
The command-line and Ant utilities scan the source directory for .task
files and then register all the .task
files found for deployment with the task plan host application.
java com.bea.wli.worklist.build.InstallTaskPlan <options>
The options and arguments to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-taskTypeSrcDir
- Holds the .task
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .task
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
Using Ant utility to install task plans into a host application:
<project name="MyProject">
...
<taskdef name="install-tasktype-in-app" classname="com.bea.wli.worklist.build.InstallTaskPlanTask"
classpath="${<Classpath that includes WebLogic Integration's public.jar}"/>
<install-tasktype-in-app
appRootDir="${<Host application's root directory>}"
taskTypeSrcDir="${<Source directory of your TaskPlan>}"/>
...
</project>
You need to deploy schemas in your application based on requirement or to support Task Plans that are associated with specific schemas.
Task plans installed within your application can refer to XMLBean data types. These data type references can define custom variants that are specific XMLBean types compiled from schemas you provide. Those schemas must be provided in the same application (or at least be visible from the application) that hosts the task plans. The simplest and recommended approach for this is to create a Schemas project at the root of your application, and include the schema XSD files under a src
directory in that project. The build facility within the Workshop for WebLogic IDE can be used to compile those schemas to XMLBeans.
You can define your own event handlers to control the operation of the Worklist-defined listeners of these types:
Your event handler can be associated with one or more task plans, and/or event types, or it can be applied globally. If the handler is associated with specific task plans, the configuration it contains will only be used for the associated task plans or event types. If an event handler is applied globally, it may be used by any task and any type of event.
To use an event handler, you must install the event handler into the Worklist host application. To install your event handler:
.handler
) file in your Worklist host application Note: | The schema of this descriptor is available in the worklist-config-binding.jar file as schema-0.xsd . For a sample of this descriptor file, see Sample of an Event Handler Descriptor File. |
InstallEventHandler
utility to install your event handler into the Worklist host application.
The Workshop for WebLogic plugin for Worklist automatically installs the event handler when you create the .handler
file, so you need not do this manually when you use Workshop for WebLogic. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing event handlers into a Worklist host application. Both these utilities require the following arguments:
.handler
files to be installed.
This directory may exist either inside or outside the application directory. If it is outside, the .handler
files is copied to a location within the application directory that matches the location of the source .handler
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
The command-line and Ant utilities scan the source directory for .handler
files, and then register all the files found for deployment with the host application.
Using the command-line utility to install event handlers into a host application:
java com.bea.wli.worklist.build.InstallEventHandler <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-handlerSrcDir
- Holds the .handler
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .handler
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
Using the Ant utility to install event handlers into a host application:
<project name="MyProject">
...
<taskdef name="install-eventhandler-in-app" classname="com.bea.wli.worklist.build.InstallEventHandlerTask"
classpath="${<Classpath that includes WebLogic Integration's public.jar}"/>
<install-eventhandler-in-app
appRootDir="${<Host application's root directory>}"
handlerSrcDir="${<Source directory of your event handler>}"/>
...
</project>
Create an Event Handler descriptor file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<java:event-handler xmlns:java="java:com.bea.wli.worklist.config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<java:global-handler>false</java:global-handler>
<java:handled-task-type-id>/MyFolder/MyTaskPlan:1.0</java:handled-task-type-id>
<java:name>My Handler</java:name>
<java:event-subscription>
<java:name>CREATE/ASSIGN Subs</java:name>
<java:event-type><java:type>CREATE</java:type></java:event-type>
<java:event-type><java:type>ASSIGN</java:type></java:event-type>
<java:email-event-subscription>
<java:java-mail-session-jndi-name>MyMailSession</java:java-mail-session-jndi-name>
<java:from-name>Me@bea.com</java:from-name>
<java:actor>
<java:name>me</java:name>
<java:type>User</java:type>
</java:actor>
</java:email-event-subscription>
</java:event-subscription>
</java:event-handler>
You can define your own custom assignment handlers by implementing the following Java interface:
com.bea.wli.worklist.api.config.AssignmentHandler
Your custom assignment handler can be associated with one or more task plans or can be applied globally. If the handler is associated with specific task plans, it is called whenever a task of that task plan is assigned to users. If an assignment handler is applied globally, it replaces any previously applied handler (including the Worklist default handler) within the Worklist system instance that receives the deployment of the handler (usually the local system instance in a stand-alone Worklist application scenario). The new global handler is called when any task is assigned to users.
Note: | Applying an assignment handler globally should be done with caution as you may overwrite a previously installed custom handler. |
To use of a custom assignment handler, you need to install it into the Worklist host application. To install your custom assignment handler:
.assign
file) in your Worklist host application Note: | The schema of this descriptor is available in the worklist-config-binding.jar file as schema-0.xsd . For a sample of this descriptor file, see Sample of an Assignment Handler Descriptor File. |
APP-INF\lib
directory of the Worklist host application as .jar
files or in the APP-INF\classes
directory as individual class files.InstallAssignmentHandler
utility to install your custom assignment handler into the Worklist host application.
The Workshop for WebLogic plugin for Worklist automatically installs the assignment handler when you create the .assign
file, so you need not do this manually when you use Workshop for WebLogic. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing assignment handlers into a Worklist host application. Both these utilities require the following arguments:
.assign
files to be installed.
This directory may exist either inside or outside the application directory. If it is outside, the .assign
files are copied to a location within the application directory that matches the location of the source .assign
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
These utilities scan the source directory for .assign
files and then register all the files found for deployment with the host application.
Using the command-line utility to install assignment handlers into a host application:
java com.bea.wli.worklist.build.InstallAssignmentHandler <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-handlerSrcDir
- Holds the .assign
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .assign
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
Using the Ant utility to install assignment handlers into a host application:
<project name="MyProject">
...
<taskdef name="install-assignmenthandler-in-app" classname="com.bea.wli.worklist.build.InstallAssignmentHandlerTask"
classpath="${<Some Classpath that includes WebLogic Integration's public.jar}"/>
<install-assignmenthandler-in-app
appRootDir="${<Host Application's root dir>}"
handlerSrcDir="${<Source directory of your handler>}"/>
...
</project>
Create an assignment handler descriptor file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<custom-assignment-handler-set
xmlns ="java:com.bea.wli.worklist.config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<custom-assignment-handler>
<global-handler>false</global-handler>
<!-- One or more handled-task-type-id elements if this is not a global handler -->
<handled-task-type-id>/MyFolder/MyTaskPlan:1.0</handled-task-type-id>
<handled-task-type-id>/MyFolder/MyOtherTaskPlan:2.0</handled-task-type-id>
<implementation-class-name>com.acme.mystuff.MyAssignmentHandler
</implementation-class-name>
<!-- Any properties you might need to properly construct your handler. Only string values are supported. These will be passed to the setProperties method of your AssignmentHandler impl -->
<property>
<name>ConstructorProp1</name>
<value>Value for prop 1</value>
</property>
</custom-assignment-handler>
</custom-assignment-handler-set>
You can define your own custom EventListeners by implementing the following Java interface:
com.bea.wli.worklist.api.events.TaskEventListener
Your custom listener may be associated with one or more task plans, event types, or can be applied globally. If the listener is associated with specific task plans, or event types, it is called when a task of that type is modified in a way that creates an event of the desired type. If the listener is applied globally, it is called when any event occurs on any type of task.
To use a task event listener, you must install it into the Worklist host application as follows:
.listener
) file in your Worklist host application.Note: | The schema for this descriptor is available in the worklist-config-binding.jar file as schema-0.xsd . For a sample of this descriptor file, see Sample of an Event Listener Descriptor File. |
APP-INF\lib
directory of the Worklist host application as .jar
files or in the APP-INF\classes
directory as individual class files.InstallTaskEventListener
utility to install your custom event listener into the Worklist host application.
The Workshop for WebLogic plugin for Worklist automatically installs the custom event listener when you create the .listener
file, so you need not do this manually when you use Workshop for WebLogic. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing custom event listeners into a Worklist host application. Both these utilities require the following arguments:
.listener
files to be installed. This folder may exist either inside or outside the application directory. If it is outside, the .listener
files will be copied to a location within the application directory that matches the location of the source .listener
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
These utilities scan the source directory for .listener
files and then register all the files found for deployment with the host application.
java com.bea.wli.worklist.build.InstallTaskEventListener <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-listenerSrcDi
r - Holds the .listener
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .listener
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
<project name="MyProject">
...
<taskdef name="install-taskeventlistener-in-app" classname="com.bea.wli.worklist.build.InstallTaskEventListenerTask"
classpath="${<Some Classpath that includes WebLogic Integration's public.jar}"/>
<install-taskeventlistener-in-app
appRootDir="${<Host Applications's root dir>}"
listenerSrcDir="${<Source directory of your listener>}"/>
...
</project>
Create a task event listener descriptor (.listener
) file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<task-event-listener
xmlns ="java:com.bea.wli.worklist.config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Unique name in the app -->
<name>MyTaskEventListener</name>
<!-- If global, task-plan-id elements are ignored -->
<global-listener>false</global-listener>
<!-- One or more task-plan-id elements if this is not a global
listener -->
<task-plan-id>/MyFolder/MyTaskPlan:1.0</task-plan-id>
<task-plan-id>/MyFolder/MyOtherTaskPlan:1.0</task-plan-id>
<!-- If true, event-type elements are ignored -->
<for-all-event-types>false</for-all-event-types>
<!-- One or more event types if this is not applied for all event types
-->
<event-type>CREATE</event-type>
<event-type>COMPLETE</event-type>
<event-type>ABORT</event-type>
<!-- Dispatch Mode (careful, sync listeners are dispatched in the same
thread in which the task update occurs, and thus runs as the user
that caused the update. Async listeners run as the run-as principal
for the TaskEventDispatcherMDB (anonymous by default, but configurable
in the WLS console) -->
<sync>true</sync>
<!-- Criticality -->
<critical>true</critical>
<!-- TaskEventListener Impl Class Name (must have public no-arg constructor) -->
<implementation-class-name>
demo.MyTaskEventListener
</implementation-class-name>
<!-- Any properties you might need to properly construct your listener.
Only string values are supported. These will be passed to the
setProperties method of your TaskEventListener impl -->
<property>
<name>Prop1</name>
<value>Hello</value>
</property>
</task-event-listener>
The above listener descriptor would install an instance of com.acme.mystuff.MyTaskEventListener
and make it applicable to tasks of type:
The listener instance is constructed using a no-arg constructor, and then it's setProperties
method is called with the properties specified in the property elements, followed by it's initialize
method.
You can define your own custom email recipient calculator by implementing the following Java interface:
com.bea.wli.worklist.api.config.EmailRecipientCalculator
The custom e-mail recipient calculator is applied globally and is invoked any time an e-mail notification is sent. When you install an EmailRecipientCalculator,
any previously applied calculator within the Worklist system instance that receives the deployment of the calculator (usually the local system instance in a stand-alone Worklist application scenario) is replaced. The new global calculator is called when any e-mail notification is sent from the Worklist email subsystem.
To use an email recipient calculator, you must install it into the Worklist host application as follows:
.email
file) in your Worklist host application Note: | The schema for this descriptor is available from the worklist-config-binding.jar file as schema-0.xsd . For a sample of this descriptor file, see Sample of an Email Recipient Calculator Descriptor File. |
APP-INF\lib
directory of the Worklist host application as .jar
files or in the APP-INF\classes
directory as individual class files.InstallEmailRecipientCalculator
utility to install your calculator into the Worklist host application.
The Workshop for WebLogic plugin for Worklist automatically installs the calculator when you create the .email
file, so you need not do this manually when you use Workshop for WebLogic. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing the email recipient calculators into a Worklist host application. Both these utilities require the following arguments:
.email
files to be installed. This directory may exist either inside or outside the application directory. If it is outside, the .email
files are copied to a location within the application directory that matches the location of the source .email
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
These utilities scan the source directory for .email
files and then register all the files found for deployment with the host application.
java com.bea.wli.worklist.build.InstallEmailRecipientCalculator <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-calculatorSrcDir
- Holds the .email
files to be installed into the target application. If this dirrectory is a child of appRootDir, no file copying is done. If not, the .email
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
<project name="MyProject">
...
<taskdef name="install-emailrecipientcalculator-in-app" classname="com.bea.wli.worklist.build.InstallEmailRecipientCalculatorTask"
classpath="${<Some Classpath that includes WebLogic Integration's public.jar}"/>
<install- emailrecipientcalculator -in-app
appRootDir="${<Host Application's root directory>}"
calculatorSrcDir="${<Source directory of your calculator>}"/>
...
</project>
Create an email recipient calculator module descriptor (.email
) file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<java:email-recipient-calculator
xmlns:java="java:com.bea.wli.worklist.config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<java:implementation-class-name>com.bea.wli.worklist.test.testEmailNotification.EmailRecipientCalculatorImpl</java:implementation-class-name>
<java:property>
<java:name>EmailDomainAddr</java:name>
<java:value>custom.worklist.drt.com</java:value>
</java:property>
</java:email-recipient-calculator>
You can define your own custom task URL calculator by implementing the following Java interface:
com.bea.wli.worklist.api.config.TaskURLCalculator
Your calculator is applied globally, and is invoked any time an email notification is sent. When you install a TaskURLCalculator, any previously applied calculator within the Worklist system instance that receives the deployment of the calculator (usually the local system instance in a stand-alone Worklist application scenario) is replaced. The new global calculator is called when any email notification is sent from the Worklist email subsystem.
To use a Task URL Calculator, you must install it into the Worklist host application as follows:
.taskurl
file) in your Worklist host application.Note: | The schema for this descriptor is available from the worklist-config-binding.jar file as schema-0.xsd. For a sample of this descriptor file, see Sample of a Task URL Calculator Descriptor File. |
APP-INF\lib
directory of the Worklist host application as .jar
files or in the APP-INF\classes
directory as individual class files.InstallTaskURLCalculator
utility to install your calculator into the Worklist host application.
The Workshop for WebLogic plugin for Worklist automatically installs the calculator when you create the .taskurl
file, so you need not do this manually when you use Workshop for WebLogic. However, if you are not using Workshop for WebLogic, Worklist provides a command-line and Ant task for installing the task URL calculators into a Worklist host application. Both these utilities require the following arguments:
.taskurl
files to be installed. This directory may exist either inside or outside the application directory. If it is outside, the .taskurl
files is copied to a location within the application directory that matches the location of the source .taskurl
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
These utilities scan the source directory for .taskurl
files and then register all the files found for deployment with the host application.
java com.bea.wli.worklist.build.InstallTaskURLCalculator <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application.
-calculatorSrcDir
- Holds the .taskurl
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .taskurl
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
<project name="MyProject">
...
<taskdef name="install-taskurlcalculator-in-app" classname="com.bea.wli.worklist.build.InstallTaskURLCalculatorTask"
classpath="${<Classpath that includes WebLogic Integration's public.jar}"/>
<install-taskurlcalculator-in-app
appRootDir="${<Host Application's root directory>}"
calculatorSrcDir="${<Source directory of your calculator>}"/>
...
</project>
Create a Task URL Calculator module descriptor (.taskurl
) file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<java:task-url-calculator
xmlns:java="java:com.bea.wli.worklist.config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<java:implementation-class-name>com.bea.wli.worklist.test.testURLCalculatorImpl</java:implementation-class-name>
<java:property>
<java:name>MyProperty</java:name>
<java:value>My Custom Value</java:value>
</java:property>
</java:task-url-calculator>
You can define your own custom task history providers by implementing the following Java interface:
com.bea.wli.worklist.api.config.TaskHistoryProvider
Your custom task history provider can be associated with one or more task plans or can be applied globally. If the provider is associated with specific task plans, it is called whenever task history is requested for a task of that type. If it is applied globally, it replaces any previously applied provider (including the Worklist default provider) within the Worklist system instance that receives the deployment of the provider (usually the local system instance in a stand-alone Worklist application scenario). The new global provider is called when task history is requested for a task of any type.
Note: | Applying a task history provider globally should be done with caution as you may overwrite a previously installed custom provider. |
To use a custom task history provider, you must install it into the Worklist host application as follows:
.history
file) in your Worklist host applicationNote: | The schema for this descriptor is available from the worklist-config-binding.jar file as schema-0.xsd. For a sample of this descriptor file, see Sample of a Custom Task History Provider Descriptor File. |
APP-INF\lib
directory of the Worklist host application as .jar
files or in the APP-INF\classes
directory as individual class files.InstallTaskHistoryProvider
utility to install your provider into the Worklist host application. Note: | The Workshop for WebLogic plugin for Worklist does not automatically install the provider as with other modules. You must do this manually to deploy your provider deployed at runtime. |
Worklist provides a command-line and Ant task for installing custom providers into a Worklist host application. Both these utilities require the following arguments:
.history
files to be installed. This directory may exist either inside or outside the application directory. If it is outside, the .history
files are copied to a location within the application directory that matches the location of the source .history
file relative to the specified source directory. If the source directory is inside the application directory, no file copying is done.
These utilities scan the source directory for .history
files and then register all the files found for deployment with the host application.
java com.bea.wli.worklist.build.InstallTaskHistoryProvider <options>
The options to this command are defined as follows:
-appRootDir
- Holds the META-INF
directory for the target application
-providerSrcDir
- Holds the .history
files to be installed into the target application. If this directory is a child of appRootDir, no file copying is done. If not, the .history
files found under this directory (recursively) are copied into the same relative path within the target application at the root of the application.
<project name="MyProject">
...
<taskdef name="install-taskhistoryprovider-in-app" classname="com.bea.wli.worklist.build.InstallTaskHistoryProviderTask"
classpath="${<Some Classpath that includes WebLogic Integration's public.jar}"/>
<install-taskhistoryprovider-in-app
appRootDir="${<Host Application's root dir>}"
providerSrcDir="${<Source directory of your provider >}"/>
...
</project>
Create a task history provider descriptor (.history
) file in your application that looks something like this:
<?xml version="1.0" encoding="ISO-8859-1"?>
<task-history-provider
xmlns ="java:com.bea.wli.worklist.config"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<global-handler>false</global-handler>
<!-- One or more handled-task-type-id elements if this is not a global
provider -->
<handled-task-type-id>/MyFolder/MyTaskPlan:1.0</handled-task-type-id>
<handled-task-type-id>/MyFolder/MyOtherTaskPlan:2.0</handled-task-type-id>
<implementation-class-name>
com.acme.mystuff.MyTaskHistoryProvider
</implementation-class-name>
<!-- Any properties you might need to properly construct your provider.
Only string values are supported. These will be passed to the
setProperties method of your TaskHistoryProvider impl -->
<property>
<name>ConstructorProp1</name>
<value>Value for prop 1</value>
</property>
</task-history-provider>