Skip Navigation Links | |
Exit Print View | |
Oracle Java CAPS Worklist Manager Service Engine User's Guide Java CAPS Documentation |
Using the Worklist Manager Service Engine
Worklist Manager Service Engine Overview
Worklist Manager Service Engine Features
Worklist Manager Service Engine Architecture
About the Worklist Manager Console
The Composite Application Project
XPath Expressions in Task Definitions
Worklist Manager Task Validation
Steps to Implement a Worklist Manager Task
Defining Worklist Manager Tasks
(Optional) Connecting to the LDAP Server
(Optional) Installing the Sample Worklist Manager Console Projects
To Install the Sample Worklist Manager Console
Creating the Worklist Module Project
Creating the XML Schema Definition (XSD)
To Create the XML Schema Definition
Creating the Worklist Manager Task Definition
To Create the Worklist Manager Task Definition
Assigning Users and User Groups to a Task
To Assign File Realm Users and Groups to a Task
To Assign LDAP Users and Groups to a Task
Configuring Advanced Task Options
Defining Time Limits and Deadlines for a Task
Defining Automatic Task Escalations
To Define Automatic Escalations
Defining Automatic Task Notifications
To Define Automatic Notifications
To Associate a Notification With a Task Status Change or Escalation
To Configure the Email BC for Task Notification
To Define a Custom Notification
Defining Trigger Actions Using the Mapper
To Define Trigger Actions Using the Mapper
Initializing Variables Using the Mapper
To Initialize Variables Using the Mapper
Creating the Worklist Manager Database
Creating the Worklist Manager Database
Creating the Database for JavaDB (Derby)
Creating the Database for MySQL
Creating the Database for Oracle
Setting the GlassFish JVM Classpath to the Database Drivers
To set the GlassFish JVM Classpath settings
Creating the JDBC Connection Pool and JDBC Resource
To Create the JDBC Connection Pool
Configuring the Service Engine to Use the Worklist Manager Database
To Configure the Service Engine for the Database
Configuring Worklist Manager Service Engine Runtime Properties
To Configure WLM SE Runtime Properties
Worklist Manager Service Engine Runtime Property Descriptions
Defining Worklist Manager Console Security
Defining Worklist Manager Console Security Using a File Realm
To Create a User Login Profile in the File Realm
To Define Security Roles for the Worklist Manager Console
To Map Groups to Security Roles for the Worklist Manager Console
Defining Worklist Manager Console Security Using LDAP
To Create an LDAP Realm in the GlassFish Server
To Update web.xml for the Worklist Manager Console (for LDAP)
To Map User Groups to Security Roles for the Worklist Manager Console (for LDAP)
To Configure the Worklist Manager Service Engine for LDAP
Including the Worklist Manager Task in a BPEL Process
To Include the Worklist Manager Task in a BPEL Process
Creating and Deploying the Composite Application
To Create and Deploy the Composite Application
Using the Default Worklist Manager Console
Installing and Deploying the Worklist Manager Console Sample
To Install and Deploy the Worklist Manager Console Sample
Logging In to the Worklist Manager Console
To Launch the Worklist Manager Console From a Browser
To Launch the Worklist Manager Console From the GlassFish Admin Console
Using XPath Expressions and Functions in Task Definitions
wlmfn:get-task-owner as xs:string
wlmfn:get-email() as xs:string
wlmfn:get-email($arg as xs:string) as xs:string
wlmfn:get-manager-email() as xs:string
wlmfn:get-manager-email($arg as xs:string) as xs:string
wlmfn:get-manager-uid() as xs:string
wlmfn:get-manager-uid($arg as xs:string) as xs:string
Entering XPath Variables in Design View
Creating Worklist Manager Task Mappings
To Create a Mapping Without Using any Functions
To Use a Function in a Mapping
To Delete a Link or Function From a Mapping
Customizing the Worklist Manager Console
About the Worklist Manager Console
Functionality and UI Semantics Specification
Customizing the Worklist Manager Console
Correcting the Task Input Data Display
Correcting the Task Output Data Display
Creating a Custom Worklist Manager Console
Creating the Web Application and Composite Application
To Configure the Web Application
Testing a deployed Worklist Manager application involves creating test cases in the composite application project that act as remote partner services. These test cases send messages to the BPEL Service Engine. When a Worklist Manager task is invoked, the BPEL SE waits for you to complete the task before the test is completed.
All steps in this section assume the following:
You have already created the Worklist and BPEL Module projects containing the required WSDL files for the operations you want to test.
You have added the Worklist and BPEL Module projects to a composite application project.
The Worklist Manager database is created and running.
Security is defined for the users and user groups to whom the tasks are assigned.
You create the test case in the composite application. When you create the test case, you need to select the WSDL operation you want to test.
The New Test Case Wizard appears.
The Select the WSDL Document window appears.
The Select the Operation to Test window appears.
In the Projects tree, a new folder is created under the Test node, containing two files: Input.xml and Output.xml.
Note - If you view the test case in the Files window, you see Concurrent.properties as a third file.
Description: A general description of the test case.
Destination: The URL from the WSDL file's <soap:address location="THIS"> tag. This identifies the location of the web service to be tested.
SoapAction: This can be left blank.
Concurrent Threads: The number of concurrent threads to run during the test. This value can be any integer. Each thread can invoke the test case multiple times (see the following property). For example, Concurrent Threads =2 and Invokes Per Thread=3, the test case will run 6 times (two threads, each run three times).
Invokes Per Thread: The number of times each thread invokes the test case. This can be any integer.
Test Timeout (sec): The length of time in seconds each thread has to finish (including completing the worklist portion of the test). If it does not finish in the allotted time, then an exception is thrown. This can be any integer.
Calculate Throughput: An indicator of whether to calculate the throughput during testing.
Comparison Type: The method in which the tester should compare the test output. Select one of the following options:
identical: Considers the output and actual output as a stream of characters.
binary: Considers the output and actual output as a stream of bytes.
equals: Considers the output and actual output as a XML documents.
Feature Status: Select one of the following options:
progress: Marks test completion as "success", regardless of the actual outcome.
done: Records the actual outcome of the test.
The test input file allows you to define the input data for the Worklist Manger application. You can modify this file after each test to run multiple tests.
Do not include the characters “<” (less-than sign) or “&” (ampersand) unless you use them with XML semantics.
If this file is empty, this is a special state that triggers a special operation when the test is run. Each time the test is run, the current output is compared to the contents of Output.xml. If any differences are detected, they are stored in the Actual_yymmddhhmmss.xml file under the test case. However, when Output.xml starts empty, the output is written to Output.xml. In each run after the first, assuming Output.xml is no longer null, its contents are preserved and is never overwritten by new results.
You can run each test case in a project individually, or you can run all tests at once.
The first time you run a test, the results correctly report that it has failed. This happens because the output produced does not match the (empty) Output.xml file, and the file's null content is replaced with the output of the first run. If you run the test again without changing the input, the second and subsequent runs report success, since the output matches the contents of Output.xml.
Test results appear in the NetBeans Output window. Detailed results are appear in the JUnit Test Results window, which opens automatically when you run a test case. If you change the value in the Input.xml and rerun the test, the following occurs:
If the Feature Status property is set to progress, the test indicates success even though a mismatch occurred.
If the Feature Status property is set to done, the test indicates failure.
If you right-click the test case node and select Diff, the window displays the difference between the latest output and the contents of Output.xml.