Service dotNet rules
|
Create a Service dotNet rule by selecting
Service dotNet
from the
Integration-Services
category.
Create a Service Package data instance before creating a Service dotNet rule; the name of the Service Package data instance becomes the first key part of a collection of Service dotNet rules.
The class and method name key parts are considered "external" and unrelated to Process Commander class and methods, for flexibility.
For example, a service that is already exported and deployed on a client computer may be changed to call a different Process Commander activity. Because the external representation and the WSDL file hasn't changed, you do not need to redeploy and modify the application code on the client computer.
A Service dotNet rule has three key parts:
Field |
Description |
Customer Package Name |
Select a package name that groups related Service dotNet rules. Choose a name already defined through a Service Package data instance. See About Service Package data instances. |
Customer Class Name |
Enter a class name to logically group related methods. This name may or may not refer to the Process Commander class that the activity belongs to, but must be a valid Java identifier. See How to enter a Java identifier. BUG-1604 |
Customer Method Name |
Enter a method name that describes the function of the Process Commander activity that the service calls; this value must also be a Java identifier. |
For general information about the New form, see Completing the new rule dialog box. For general information on the Save As form, see How to enter rule keys using Save As.
TFFF When searching for a Service dotNet rule, the system filters candidate rules based on a requestor's RuleSet list of RuleSets and versions.
Circumstance-qualified and time-qualified resolution features are not available for Service dotNet rules. The class hierarchy is not relevant to Service dotNet rule resolution.