|
|
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.
-listenerSrcDir - 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 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 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>
|