Administration Console > Admin > Configure Server
  

Configure Server

After selecting the Configure Server command, Process Server displays the following page:
Configure Server page
Configure Server page
Configure Server topics include:

Server Properties

To see the Server Properties, select an agent from the Console list.
On the Server Properties page, you can make configuration changes without stopping and restarting the engine. When you change the properties and select Update, the changes take effect immediately. The changes are also written to the database and propagated to other engines in the cluster.
View and update Server configuration settings as shown in this topic. Note that some of these properties are the same as the Process Developer Simulation preferences.
Allow proxy user in process invocations
A process can have a policy assertion (called Run as User) that enables a named user to be a process initiator, as opposed to the normal process initiator with credentials or an anonymous user. If desired, you can disable this property and the policy assertion is ignored. This setting applies to all new process instances and is enabled by default.
Auto create target path for Copy/To
Applies only to processes that are validated against the BPEL4WS 1.1 specification. For WS-BPEL 2.0 processes, this property can be added as an extension on a per process basis. Refer to the Process Developer Guide for more information.
This property determines if Process Server can create a location path for a non-existent node in a complex variable in a process instance document. When an assignment refers to a non-existent node (or to more than one node), the standard BPEL fault, bpws:selectionFailure, must be thrown, according to the BPEL specification.
Enabling this option allows selections to be created on-the-fly. This means an assign copy TO operation can refer to a non-existent node and assign a value to it. This option is disabled by default.
Contribution Cache
Setting this cache controls how many contributions are kept in memory. This cache avoids having to read the database too often. Generally contributions are small. However, the size depends on how many resources (that is, catalog entries) they contain and how many imports and exports they have.
Changing the default value depends on the number of deployed contributions and the amount of memory available. The default is 100 contributions. If a contribution is cached, it need not be looked up in the database. If you have more than 100, you may want to increase this value.
This cache setting doesn’t require much tuning and profiling the application server is probably required to determine if changing this value would improve performance.
This cache is not set in the Server Properties dialog. Instead, you will need to set this in the engine configuration file, which is aeEngineConfig.xml, which is contained in the activvos.war file.
Deployment Lock Timeout (seconds)
In a clustered environment, one machine acquires a deployment lock, and the other machines must wait until deployments are complete before starting .bpr deployments. If you have many machines in a cluster, you may need to increase the timeout value because each machine deploys many system .bprs upon start-up. The default value is 120 seconds.
Deployment Plan Cache
A deployment plan corresponds to each deployed version of a process, including associated disposition of running processes. Process versions that are active can be cached for better engine performance. The default number of plans that are cached is 100. For details regarding versions, see Process Version Life Cycles.
Disable bpws:selectionFailure fault
Applies only to processes that are validated against the BPEL4WS 1.1 specification. For WS-BPEL 2.0 processes, this property can be added as an extension on a per process basis. Refer to the Process Developer Guide for more information.
This option allows an XPath query in the FROM clause of an assignment statement to return an empty node set. If it does, the target node for the assignment is deleted.
By default, this option is not enabled, and if the query string returns an empty selection from an assign copy FROM, the process throws a bpws:selectionFailure fault, which is the standard response described in the BPEL4WS specification.
Maximum HTTP Connections/Maximum HTTP Connections Per Host
If you have several HTTP Invokes within a process, the Invokes could spawn more than 100 connections. If this occurs, you should, you should increase the default maximum number of HTTP Connections value so that multiple threads are not suspended waiting to create a HTTP Connection. (You will see service call timeouts when this happens.)
Changes you make do not occur until you restart the server.
Message size limit
Sets the maximum size of the payload for a multi-part message that does not have attachments.
If you use the Informatica Cloud Server, you can set a maximum message payload size of 5 MB.
If you use a Secure Agent, the default value is 5 MB, but you can change set a higher or lower value.
Message with attachments size limit
Sets the maximum size of the payload for a multi-part message that has attachments.
If you use the Informatica Cloud Server, you can set a maximum message payload size of 5 MB. The maximum size for attachments is also 5 MB.
If you use a Secure Agent, the default message payload size is 5 MB and the default attachment size is 5 MB. You can change the default sizes to set higher or lower values.
Migrate running processes even on warning
If Migrate is selected as a deployment option on a contribution, running processes are migrated to the new process version. The server checks for compatibility between the old and new process plans and generates a warning in the Process Server Log if an incompatibility exists.
Be sure that the Process Server Log is set to at least Warning Level before any migration is attempted.
If this property is disabled (the default), and if a warning condition exists for one or more running process instances, a copy of each running process instance is created, and both the pre-migration copy and the new copy are suspended. Additionally, a warning code/message is added to the Process Server Log.
If this property is enabled, no copy of the running instance is made if a warning condition exists. The only action is that a warning code/message is added to the Process Server Log.
For details, see Migrating Running Processes when Warnings are Generated .
Process Count
Specifies the maximum number of processes in memory. The default number is 250. Specifying 0 indicates no limit, but this is not recommended.
Process Idle Timeout
Specifies the number of seconds to wait until process state information is written to the database during idle processing times such as waiting for a reply from an invoked service. You can increase the timeout value to enhance engine performance. You can decrease the value to ensure the full process state is always in the database. Doing so avoids potential process recovery time in the event of a server failure. The default is 10 seconds.
Resource Cache
The number of WSDL files and other resources in stored cache. The default is 100. Modifying the cache size may improve engine performance. A value of -1 means unlimited caching, but this is not recommended.
Screen Cache Size (MB)
Sets the size of the cache Process Server uses for storing screens used by guides. Guides can be large in size when they are published and generally not every single path in the guide is always executed. This cache holds the HTML for the most commonly used screens within a guide. This improves the time required to load a screen as the guide containing the screen need not be loaded.
Suspend process on invoke recovery
For invoke activities which do not complete due to the node failure, you can suspend the process upon recovery. The process is suspended at the pending invoke, and you can perform process exception management, if desired.
An individual process can override this setting with an entry in the PDD file.
Suspend process on uncaught fault
According to the WS-BPEL 2.0 specification, a process with an uncaught fault terminates.
Enable this option to suspend all processes on an uncaught fault to put them in a suspended-faulting state. You can then perform process exception management on the faulting process such as retrying or completing the faulting activity or scope.
An individual process can override this setting with an entry in the PDD file. See Exception Management Type.
See Process Exception Management .
Terminate suspended process after (days)
Suspended processes stay in the Active Processes list indefinitely, if they are not otherwise resolved.
Enter the number of days to retain suspended processes, for example, 30 days. The suspended processes are terminated automatically after the retention period is reached.
By default, this option is set to 0, meaning suspended processes are never terminated. For processes running on the Cloud Server, this option is determined by Informatica.
Unmatched Correlated Receive Timeout
Sets the number of seconds that the Process Server waits to match a correlated message to a message activity or an event activity if the message arrives before the activity becomes active. Set this value to avoid many unconsumed messages on the server.
The default value is 30 seconds. If you enter an Unmatched Correlated Receive Timeout of 0 seconds, the Process Server discards all unmatched correlated messages when they arrive.
If the Process Server crashes, it recovers messages and continues to wait until a relevant consumer consumes the messages, or until a timeout occurs.
If the Process Server waits for a time that is longer than the value you specify, a timeout occurs. When a time out occurs, the Process Server adds a correlation violation error to the server log. This correlation violation error does not contain any message details. The correlation violation error contains a unique hash key called AeSecuredLogDatakey, a concatenation of the Engine ID, Plan ID, Queue ID, and Timestamp in milliseconds of when error occurred.
The following is a sample correlation violation error:
correlationViolation [AeSecuredLogDatakey=786000_123456_1000_1476434734123;tenant=ABCDEF; planId=123456;partnerLink=MessageEvent1EventPL;operation=Initiate]
To view message details such as the service name, operation name, and message parts, search for AeSecuredLogDatakey in the AeSecuredLogData table.
The correlation violation error contains the hash key and not the message details because the message details might contain secure information. This two-step method secures your data.
To view the number of queued messages, go to Process Console > Monitor > Monitor > Server Monitoring > System Performance.
To view the number of messages that the Process Server discards because of a time out, go to Process Console > Monitor > Server Monitoring > Server Statistics
Validate input/output messages against schema
Validates the data used in service interactions against their associated schema.
Enable this option to validate data before execution starts. Disable this option for faster execution. This option is enabled by default.
Web Service Invoke/Reply Timeout
For performance reasons, a reply activity matching a receive, as well as synchronous invokes, are timed out if they do not execute within 10 minutes. If you are receiving timeout errors, you can specify a greater amount of time to wait before a process is timed out due to a reply or synchronous invoke activity not executing within 10 minutes.
The default is 600 seconds.
Work Manager Thread Pool Max
Set the maximum number of execution threads the engine can spawn simultaneously. The default is 300. A value of -1 means that there is no maximum number of threads.
This property does not appear in the Process Console if Process Server is configured to use an application server Work Manager.
If the number of threads being run is equal to this value, processes can fault as no threads are available when a node needs to broadcast information to other nodes. To be safe, you should create a secondary pool to be used by Process Server. (This is done in the Process Console. Process Server will only use threads in this pool when critical system work must be performed.)
Work Manager Thread Pool Min
Set the minimum number of execution threads the engine allocates for its work manager. The default is 25. A simple rule of thumb is to have enough work threads to run the number of processes plus the number of simultaneous invokes that processes may execute.
This property does not appear in the Process Console if Process Server is configured to use an application server work manager.
Work Manager Threads For Alarms Max
Set the maximum number of threads the engine will use from the work manager to dispatch work scheduled by an alarm in a process. If there are 100's of alarms firing concurrently, all of the threads in the work manager could be used just to dispatch the alarms. If you experience performance issues or deadlocks because the alarm manager is using all of the threads, you can increase this value. The default is 5.
Work Manager Threads For Process Migration Max
Increase the thread count if you have hundreds of processes to migrate. This count is on top of execution threads for the server The default is 50 and affects the number of threads allocated for new receives. For details, see the server property above, Migrate running processes even on warnings.
Work Manager Threads Per Process Max
Set the maximum number of execution threads the engine can spawn simultaneously for an individual process. The default is 10.

JMS Exception Listener

The Process Server establishes a JMS Exception Listener for each connection it maintains. If after the server established a connection, it receives a connection failure notification, it attempts to reconnect for a specified interval and number of attempts. The default is 30 seconds (30,000 milliseconds) for 20 attempts.)
Use the following SQL statements to change these values:
INSERT INTO AeConfigSettings (ConfigPath, ConfigValue)
VALUES ('MessagingManagers/<manager name>/ReconnectionInterval', '30000');
and
INSERT INTO AeConfigSettings (ConfigPath, ConfigValue)
VALUES ('MessagingManagers/<manager name>/ReconnectionAttempts', '20');
The only time you might want to change these values is when the default length of time is too short. If the Process Server cannot reconnect because the connection listeners are not notified, changing these settings won't help.

Logging Properties

On the Logging Properties page, you can select logging levels for the Process Server and for processes.
Property Name
Description
Server Logging Level
By default, Process Server generates a log of server events, including server property configuration changes, BPR deployments, server stop and start, and process failures. You can set the logging level as follows:
  • - Info
  • - Error
  • - Warning (default)
  • - Critical
  • - Verbose (includes all levels)
  • - Off (No logging occurs)
Process Logging Level
By default, Process Server generates an execution log for running processes. You can view or download an execution log for a running or completed process. An execution log provides start and end times for activity execution and helps you troubleshoot faulted processes. The logging levels are:
  • - None: The Process Server does not log any information. Use this option to enhance engine performance.
  • - Fault:The Process Server logs only fault information. If no faults occur in a process, the Process Logging level defaults to None. Select Fault to reduce the size of the log file.
  • - Execution:This is the default option. The Process Server logs all execution statements except for Will Not Execute statements. Select Execution to decrease the size of the log file.
  • - Fault:The Process Server logs only fault information. If no faults occur in a process, the Process Logging level defaults to None. Select Fault to reduce the size of the log file.
  • - Execution with Data: The Process Server logs all execution statements except for Will Not Execute statements, but includes variable, expression, and partner link data. Select Execution with Data to decrease the size of the log file.
  • - Execution with Service Data: The Process Server logs all execution and fault information, as well as some WSIO activity information. For execution information, Process Server logs deadpath states, terminations, ready-to-execute, and so on. For WSIO, Process Server logs invokes, picks, and receives, but excludes information related to data assignment and changes.
  • - Full: The Process Server logs all execution statements Will Not Execute statements for deadpath activities. For example, the Process Server logs all fault handling statements that are not executed.
To improve processing speed, perform no logging or minimum logging. Informatica recommends that you use the None or Terse logging levels.
Max Process Logging Level
Note: This option is not available in the Process Console for agents.
It is also possible to set logging options on individual processes. In some cases, the individual process logging level may exceed what is specified here as the global Process Logging Level.
To set an overall limit on the logging level, you can select a maximum permitted level in this field. Even if individual processes set a higher logging level in the PPD file, the logging level never exceeds the option set in this field.
For example, if you set an individual process tracing level to Verbose, the logging level of the process is set to Execution with Data. However, if you also set the Max Process Logging Level to Execution with Service Data, this lower maximum logging level would be applied to the process at runtime.
Max Buffer Size (number of logging events)
The number of state changes, data changes, and other logging events that the Process Server holds in a buffer before writing them to the database. The default value is 200.
Persist Interval (seconds)
The number of seconds that the Process Server waits before flushing the buffer and writing log events from memory to the database. The default value is 30.
Log all messages
If enabled, logs data of each WS message going to and from the Process Server, including OData requests, and SOAP envelope, headers, and body. All HTTP messages are logged to the file system.
Logging Base Directory
Root directory for log files. The default base directory is the location pointed to by the java.io.tmpdir property. When messages are logged, each engine will create message log files under the root directory under <BASE_LOGGING_DIRECTORY>/engine<id>/.
The configuration for the base logging directory can contain ant-style parameters that are resolved relative to system properties and environment variables. For example, ${CATALINA_HOME}/logs will create log files relative to the CATALINA_HOME environment variable used to start your Tomcat server.

Global Function

On the Global Functions page, you can add custom function information for any process on the server. These functions are not within the scope of a contribution.
BPEL processes may contain custom functions that are used within XPath or other expression languages. Process Server provides a FunctionContext interface for implementation of custom functions. By using the FunctionContext interface, new or different functions may be installed and made available to the Process Server XPath (or another) expression writer.
If you already have custom functions implemented with a different interface, such as the jaxen FunctionContext interface, you can use them in your BPEL process.
Global Functions page
If you have not yet written custom functions, you can download a BPEL process example from the Education Center on http://www.active-endpoints.com. The Custom Function sample includes all the necessary source files for using custom function in Process Developer and on the Process Server.
Compiling your Custom Function with Function Context Classpath References
To implement the Java-based FunctionContext interface, you'll need the files that are within:
[Process Developer product folder]\developer\plugins\org.activebpel.enginep_[version]\server\shared\lib
You will use org.activebpel.rt.bpel.function.IAeFunctionContext contained within ae_rtbpel.jar in order to implement the FunctionContext interface. If you are implementing exception handling, you'll need ae_rt.jar.
Adding Global Functions to Process Server
You add custom function details to make the functions known to the engine.
You can specify an absolute classpath location for the function or use a system property to indicate a location that any server in a cluster can point to. You define the system property as appropriate for your application server. You'll add the following information to the Add Global Function Details section.
After adding this information, press the Add/Update Context button.
Process Server validates the function details and ensures that a class loader can load the class files.
If an error is reported, ensure that you have a valid class name and classpath location for the custom function on the same machine as the Process Server.
You can delete any function that you no longer need if you delete the associated processes.

Monitoring Thresholds

On the Monitoring Thresholds page, you can select engine properties to monitor. For each property, you can provide a statistic and threshold that, when reached, alerts you to a warning or error condition.
Monitoring Threshold page
You can decide what the frequency and interval of monitoring periods should be, as described in the following table.
Field
Explanation
Threshold Period
Period for collecting and aggregating statistics. The default is five minutes.
Evaluation Frequency
Number of times during the threshold interval the statistics are evaluated. For example, if the threshold interval is five minutes, and the evaluation frequency is five times, then statistics are collected and aggregated once a minute during every five-minute period. The default is 5 times.
Maximum Trouble Items
Number of error/warning items per engine to display on the Monitoring page of the Process Console
Monitor Alert Service
Described after this table.

Monitor Alert Service

Add the name of the service that will run when errors and warnings occur for monitored properties. This service also runs when it automatically triggered by a MultiSite site unavailable status. (MultiSite require a special license.)
When errors occur, the Process Server instantiates the alert service, which can then invoke an action, such as notifying an administrator that a monitored property has an error condition. The service can also monitor engine status (running or stopped).
To add a service, type in the Service name, and select Update.
The service name is the My Role partner link service, identified in the PDD file deployed with the BPEL process to be used as the alert service. You can find this name by looking on the Service Definition page.
After you add the service, select View Details to view the BPEL process.
For details on how to create an alert service, see Alert Service in the Process Developer help.

Selecting Server Properties to Monitor

Use the following procedure to monitor a property, press the Add Row button. Process Server adds a row and within this row, .
Set the property by filling in this row, as follows:
After adding properties, select Update.
You can now go to the Server Statistics page to view the results.

Monitoring Properties

The properties you can monitor are as follows:
Cluster communications issue detected (count)
The number of times an issue with broadcasting cluster messages to nodes was detected.
Critical storage exceptions (count)
Storage exceptions include:
Database connection acquisition time (ms)
Tracks the amount of wait time to get a connection from the datasource. An excessively long wait may indicate signs of trouble with the size of the connection pool. The monitoring includes maximum and average values.
The Process Server storage layer does not perform connection pooling. It relies on the storage implementation (usually a javax.sql.DataSource) to pool connections. Consult your application server or database documentation to address any issues with poor performance related to the connection pool size or connection acquisition time.
Deadlock retry attempts (count)
A deadlock retry can occur when the engine attempts to:
Discarded unmatched correlated receives (count)
When a message with correlation properties fails to route to a running process instance and is not able to create a new process instance, the engine will keep trying to dispatch the message for the configured amount of time. There is a limit to the number of such unmatched messages that the engine will retry. This property tracks the number of messages that were discarded due to the buffer of unmatched messages being full.
The unmatched correlated receive timeout, which is shown on the Server Properties page, controls the amount of time that the engine will keep the unmatched message queuing until it is routed to a process instance. The pool of unmatched receives may fill up if this timeout is too high. However, such a problem may be an issue with process design as opposed to the timeout or buffer size.
Engine removed from cluster (count)
The number of times an engine was removed from a cluster due to it going offline, missing cluster broadcast messages.
Failed to lock process (count)
In the event of a failover, a process instance that began on one cluster node may be moved to a different node during recovery. It is unusual, but possible, that a process lock may fail, causing a process to suspend in the Suspended (programmatic) state. To address this problem, configure this property by set a Warning level for a count greater than 1 (or similar threshold).
By monitoring this property, as well as monitoring the Server Log for process recovery messages, you can determine if unwanted process suspensions are being caused by process lock failures.
Faulted/suspended(faulting) processes (count)
Number of processes that end in a faulted state or are suspended due to an uncaught fault.
You may have an expectation that processes running on this engine should not fault, and you want to be notified if they do. Also see Alert Service for a description of the Alert Service that enables you to configure a service for notification of faulted processes.
Plan cache efficiency (percent)
Helps you determine if the Deployment cache setting is correct.
A deployment plan corresponds to each deployed version of a process, including associated disposition of running processes. Process versions that are active can be cached for better engine performance. The default number of plans that are cached is 100.
Plan cache removals (count)
The number of times process plans were removed from the cache.
Plan cache turnover (percent)
How often loading of new plans forced older plans out of cache.
Process cache efficiency (percent)
The engine configuration contains a count of the maximum number of processes which can be kept in memory before they are forced into storage.
A process is cached in memory if it is currently executing some logic or if it is quiescent but is being cached in anticipation of receiving another message, alarm, or response to an invoke. This property reports the percentage of processes that are read from memory versus process instances read from storage. For example, 100% indicates that all process reads are coming from the memory cache.
On the Server Properties page, you can set values for Process Count and Process Idle Timeout. The Process Count setting controls the size of the cache. The Process Idle Timeout setting controls how long to keep an idle process in the cache. If the process cache efficiency percentage is low and your processes contain bi-directional invokes or can process multiple inbound messages, you may benefit from increasing the Process Count and Process Idle Timeout. This will help keep processes in memory. However, if your processes are long-running and receive messages only periodically, a low process cache efficiency percentage is not necessarily a problem.
Process count exceeded (count)
The Server Properties include a Process Count option that specifies the maximum number of processes in memory. When the process count exceeds the value set for the Process Count, you can create an alert based on this property.
For example, if the Process Count is set to 50 and you want to be alerted when the count reaches 55, set this value to alert when the threshold is greater than or equal to 5.
Time to obtain plan (count)
The amount of time it takes to load a process plan into memory.
Time to obtain process (ms)
The time it takes to obtain a process is useful to determine if this operation is trending significantly higher under load situations. The monitoring includes maximum and average values. This property includes the time it takes to acquire a lock on a process as well as restore its state from storage if necessary.
This property works in conjunction with process cache efficiency.
Time to perform XSL transform (ms)
The time spent performing transforms within the doXslTransform() custom function.
Time to query Identity provider (ms)
Amount of time spent querying the identity provider in milliseconds. For example, if a request to the LDAP server to list groups for a user takes 20ms, that’s the value of this metric for that instance.
This property allows you to track down slowness issues with an LDAP provider if you track a spike in time to query
Time to save process
Number of milliseconds required to save the process state and variables to the database.
A threshold can vary greatly depending on the process composition, number of variables, and size of variable data. This property only works for processes with a persistence setting of Full or Persist.
Time to validate messages (ms)
Reports the amount of time the engine spends validating input and output messages from receives, invokes and other activities.
This validation is enabled on the Configuration page labeled: "Validate Input/Output messages against schema." If enabled, all messages are validated. Validation can also be enabled or disabled on individual partner links through a policy assertion.
This property does not track the time spent in explicit variable validation through the BPEL validate activity or optional validate attribute on the assign activity.
You may wish to speed up processing by disabling all or selected message validation. If too much time is spent validating messages, you can take several steps. Start by redeploying processes with an added Message Validation policy assertion for partner links, which provides fine-grained control over specific types of messages. You can also disable message validation for all processes by disabling the Server Property.
Work manager work start delay (ms)
The time it takes between scheduling of a work item request and the actual start of work can help in tuning of the work manager pool.
If the time delay is trending upwards, there may not be enough threads available to handle the amount of work. The monitoring includes maximum and average values.
If you are using the default work manager, the size of the work pool can be configured on the Server Properties page. If you are using a work manager implementation provided by an application server, the size of the pool and the priorities of its threads should be configurable in your application server administration console.

URN Mappings

On the URN Mappings page, there are system mappings and user-defined mappings.
URN page
System Mappings
Process Server provides the following default URN Mappings for system services. You may need to manually add a mapping if it wasn't part of your initial configuration.
URN
URL
ae:internal-reporting
http://localhost:8080/activevos/internalreports
Default address of the BIRT reporting engine for a deployed process containing a reporting service.
ae:report-proxy
The address of your reverse proxy server base; for example, http://localhost:9800. Only set this URN when you need ro configure the reverse proxy location for BIRT to use in the form of a URN mapping
ae:task-inbox
http://localhost:8080/activevos-central/avc
Default address of Process Central. Be sure to change the host:port to match your installed location, if needed.
java:comp/env/jdbc/ActiveVOS
This value is created using your specified JNDI database name
User-Defined Mappings
You can assign a physical address to a universal resource name (URN). The URN is a logical address of a partner link, specified in a deployment resource.
URN mappings provide a flexible and dynamic way to define target endpoint references. Use URN mappings to specify the physical address of a partner link endpoint reference instead of using the address specified in a process deployment descriptor (.pdd) file or WSDL file. By mapping a URN to a URL, you do not have to rely on invoking a statically defined endpoint address. URN mappings give you flexibility, for example, to deploy the same BPR files for testing and production environments.
Also, if you specify a URL, you can replace the URL by mapping it to a different URL.
The following example illustrates one type of URN to URL mapping:
urn:localhost = http://localhost:8080/active-bpel/services/${urn.3}
This mapping might be used when a process is deployed with the following partner link address information:
<partnerLink name="assessor">
   <partnerRole endpointReference="static"
     invokeHandler="default:Address">
      <wsa:EndpointReference xmlns:assessor="http://
       tempuri.org/services/loanassessor">
      <wsa:Address>urn:localhost:AssessRisk</wsa:Address>
      <wsa:ServiceName PortName=
        "SOAPPort">assessor:LoanAssessor</wsa:ServiceName>
   </partnerRole>
</partnerLink>
The Process Server invocation framework resolves the URN as follows:
urn:localhost:AssessRisk = http://localhost:8080/active-bpel/services/AssessRisk
Here are some ways you can map URNs to URLs. Note that each segment of the URN is separated by a colon.
URN
URL
urnSegment1:urnSegment2
http://localhost:8080/active-bpel/services/MyService
http://ServerA:8080/active-bpel/services/MyService
http://ServerB:8081/active-bpel/services/MyService
urn:localhost:service
http://localhost:${AE-NODE1-PORT}/active-bpel/services/${urn.4}
The last example in the table above shows how you can use variable substitution in an URL.
The URL values can optionally contain variables. The variables can be environment variables accessible through java.lang.System.getProperties() or a segment from the URN itself. The Apache Ant style variable declaration of ${property} is used to identify a property within the URL. Segments from the input URN value can be referenced by using a special property naming convention of ${urn.offset} where offset is a one-based offset identifying the segment from the input URN value to use for substitution.
The URL in the third mapping in this table contains two variables. The ${AE-NODE1-PORT} variable pulls the port number from an environment variable. This variable would need to be set as a -D parameter on the Java runtime environment (for example, java -D AE-NODE1-PORT =8080 ...) or populated externally to the Process Server.
The ${urn.4} variable, also in this example, references the fourth segment from the input URN value. Notice that the URN contains only three segments. The URN in the .pdd file should contain at least one other segment. A sample URN might be:
urn:localhost:service:StoreService.
As the value of the fourth segment of this URN is StoreService, the resulting URL is:
http://localhost:8080/active-bpel/services/StoreService/
Managing URN Mappings
Operations you can perform are: