Click OK. How to Create Static Routing Rules

Creating Oracle Mediator Routing Rules 19-9 ■ For synchronous operations with a conditional filter, the echo option does not return a response to the caller when the filter condition is set to false. Instead, it returns a null response. ■ The echo option is available for asynchronous operations only if the Oracle Mediator interface has a callback operation. In this case, the echo is run on a separate thread.

19.2.2.3 How to Specify Sequential or Parallel Execution

A routing rule can be executed either in parallel or sequentially. To specify an execution type for a routing rule, select the Sequential or Parallel execution type in the Routing Rules section. Basic Principles of Sequential Routing Rules Oracle Mediator processes sequential routing rules based on the following principles: ■ Oracle Mediator evaluates routings and performs the resulting actions sequentially. Sequential routings are evaluated in the same thread and transaction as the caller. ■ Oracle Mediator always enlists itself into the global transaction propagated through the thread that is processing the incoming message. For example, if an inbound JCA adapter invokes an Oracle Mediator, the Oracle Mediator enlists itself with the transaction that the JCA adapter has initiated. ■ Oracle Mediator propagates the transaction through the same thread as the target components while executing the sequential routing rules. ■ Oracle Mediator never commits or rolls back transactions propagated by external entities. ■ Oracle Mediator manages the transaction only if the thread-invoking Oracle Mediator does not already have an active transaction. For example, if Oracle Mediator is invoked from inbound SOAP services, Oracle Mediator starts a transaction and commits or rolls back the transaction depending on success and failure. Basic Principles of Parallel Routing Rules Oracle Mediator processes routing rules in parallel based on the following principles: ■ Oracle Mediator queues and evaluates routings in parallel in different threads. The messages of each Oracle Mediator service component are retrieved in a weighted, round-robin fashion to ensure that all Oracle Mediator service components receive parallel processing cycles. This is true even if one or more Oracle Mediator service components produce a higher number of messages compared to other components. The weight used is the message priority set when designing an Oracle Mediator service component. Higher numbers of parallel processing cycles are allocated to the components that have higher message priority. Note: The asynchronous echo option is available only when the routing rule is parallel. If you use the echo option, then sequential routing rules are not supported for Oracle Mediators with asynchronous operations. 19-10 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite You can set the Priority field in the Mediator Editor to indicate the priority of an Oracle Mediator service component. Priorities can range from zero to nine, with nine being the highest priority. The default priority is four. ■ Oracle Mediator initiates a new transaction for processing each parallel rule. The initiated transaction ends with an enqueue to the Oracle Mediator parallel message dehydration store. For example, if an Oracle Mediator service component has one parallel routing rule, one message is enqueued on the Oracle Mediator parallel message dehydration store. The parallel message dispatcher to the store then initiates a transaction, reads the message from the database store, and invokes the target component or service of this routing rule. The transaction initiated by the listener thread is a completely new transaction and is propagated to the target components. ■ Oracle Mediator commits or rolls back transactions because it is the initiator of these transactions. If an operation or event has both sequential and parallel routing rules, first sequential routing rules are evaluated and actions are performed, and then parallel routings are queued for parallel execution.

19.2.2.4 How to Configure Response Messages

In the Oracle Mediator routing rules, you can specify how to handle the response messages in synchronous and asynchronous interactions. For synchronous interactions, you can specify the transformations and assignments for the response and the fault message. You can forward the response and the fault message to another service or event, or you can send them back to the initial caller, if the initial caller is expecting responses and faults. For asynchronous interactions, you can specify transformations and assignments, and a timeout period for receiving the response. The timeout period can be specified in seconds, hours, days, months, or years. By default, the timeout period is infinite. If a callback response does not come within the specified timeout period, a timeout response can be forwarded to another service, to another event, or back to the initial caller. Note: The Priority property is applicable only to parallel routing rules. Note: Dehydrating of messages means storing the incoming messages in a database for parallel routing rules so they can be processed later by worker threads. Note: If an Oracle Mediator service component with a request-response interface has only parallel routing rules, the Oracle Mediator service component does not send a response back to the caller. Though you can create this type of Oracle Mediator service component, the caller of the Oracle Mediator service component does not receive a response at runtime.