OSB 12c : Dynamic Routing to Business/Proxy Service

Dynamic routing is a kind of  Content-based Routing pattern, which is used when the BusinessService/ProxyService path is required to be determined at run time, an alternative to Static Routing, which is used when the BusinessService/ProxyService path is established during design time.

As for example, if there are different services eg. BusinessService1, BusinessService2, ProxyService1 that are each based on the same interface, we can use dynamic routing.

The core of this feature is built on the following XML element:

<ctx:route>
<ctx:service isProxy=”true|false”>{$proxy|$businessService}</ctx:service>
<!– Optional : –>
<ctx:operation>{$operationName}</ctx:operation>
</ctx:route>

The isProxy is true or false according to whether the dynamic route is to a Proxy Service or to a Business Service respectively.

Operation is an optional element and is used when you want to invoke a particular operation of a multi-operation ProxyService.

Note: The text inside the Expression tab is a string literal. Any XQuery expressions must be wrapped by braces {}.

The above element in the expression of a dynamic routing action inside a route node, etc. looks like this when executed:

BS:
<ctx:route>
<ctx:service isProxy="false">ServiceCalloutTest/BusinessService1</ctx:service>
</ctx:route>

PS:

<ctx:route>
<ctx:service isProxy="true">ServiceCalloutTest/ProxyService1</ctx:service>

<ctx:operation>initiate</ctx:operation>
</ctx:route>

Now say based on some field element in the input or some variable value you fetch within your pipeline you want to route to a BS or a PS.

Your element variable assume here is alias which can have values say US, IND at runtime based on which you route to the service.

We will create RoutingTable variable on that basis like below using an assign activity.

<Services>
<Service>
<alias>US</alias>
<physical>ServiceCalloutTest/BusinessService1</physical>
</Service>
<Service>
<alias>IND</alias>
<physical>ServiceCalloutTest/BusinessService2</physical>
</Service>
</Services>


So finally in your Dynamic Routing activity below is the expression:

<ctx:route>
<ctx:service isProxy='false'>{$RoutingTable/Service[alias/text()=$alias]/physical/text()} </ctx:service>
</ctx:route>

In the request pipleline you can add activities for process the body/header etc based on what you need to send to the endpoint service

Save and activate your service and Test to verify if working as expected.


Helpful? Comment

Happy Learning.

OSB 12c : Create & Configure Work Manager, Max, Min Thread Constraints

Firstly a little bit of theory. Its important you understand the concept of WM (and its as per Oracle documentation).

WebLogic Server uses a self-tuning thread pool for executing all application-related work. The pool size is managed by an increment manger which adds or removes threads to the pool when it deems it necessary.

The number of active threads will never exceed 400. 

As requests enter the server, a scheduler manages the order in which the requests are executed. When the number of requests exceeds the number of available threads, they are queued and then executed as threads return to the pool and become available. 

Work Managers indicate the type of work and priority of a request to the scheduler.

The following concepts are important to consider when assigning Work Managers to services.

1. Request and response pipelines always execute in separate threads. While the request thread originates from the proxy service transport, the response thread originates from the business service transport.

2. When external services are invoked, threads can be blocking or non-blocking, depending on the pipeline action, the Quality of Service (QoS) configuration, and the transport being used.

3. When using blocking calls, a Work Manager with a minimum thread constraint must be associated with the response in order to prevent server deadlocks.

Two key properties when configuring a Work Manager are Max Thread Constraints and Min Thread Constraints.

A maximum thread constraint limits the number of concurrent threads executing a type of request by restricting the scheduler from executing more than the configured number at one time. However, the thread pool is shared among all Work Managers, so there is no guarantee the maximum number of threads will be available for processing at any given time.

A minimum thread constraint guarantees a minimum number of threads for processing. If sufficient threads are not available in the thread pool to process up to the minimum number, the scheduler uses standby threads to satisfy the minimum. Standby threads are not counted as part of the maximum number of 400 threads in the pool. When a thread is executing a request associated with a Work Manager containing a minimum thread constraint, the Work Manager first checks the queue for another request associated with the same constraint and executes it (instead of returning to the free pool). For this reason, use minimum thread constraints judiciously. Over-use can cause resource starvation of the default Work Manager, leading to unpredictable results.

The Work Manager (dispatch policy) configuration for a business service should depend on how the business service is invoked.

If a proxy service invokes the business service using a service callout, a publish action, or routing with exactly-once QoS, consider using different Work Managers for the proxy service and the business service instead of using the same for both. For the business service Work Manager, configure the Min Thread Constraint property to a small number (1-3) to guarantee an available thread.

Now after all the theoretical details we will see how we can configure work manager in OSB 12c. The concept is similar to that of 11g however the screens have changed for OSB applications.

1. Login to Admin Console : http://host:port/console

2. Click on Lock & Edit

3. Navigate to Environments > Work Managers

4. Create New

5. Select Maximum/Minimum Thread Constraint (which ever you want to create)

6. Provide Logical Name and Count - say MaxThread4 and 4

7. Click on Next 

8. Choose the target server

9. Finish

Now again click on New 

1. Select Work Manager

2. Provide a Logical Name

3. Click Next

4. For Max and Min Threads Constraint from the drop-down select the ones you have created above

5. Finish and your WM is created with the constraints

Now assigning the WM to your service

1. Login to Service Bus console

2. Create Session

3. Navigate to your Proxy or Business Service

4. Under Transport Details Tab > from drop-down select your WM you have created.

5. Save and then Activate your session 

Helpful? Comment

Happy Learning!

OSB 12c : Enable/Disable Proxy service

In case you are using an OSB Proxy Service for polling and want to disable/enable the service, you can carryout out the below steps.

11g Steps:

1. Login to sbconsole. http://hostname:port/sbconsole

2. Select the Proxy service
3. Click on 'Operational Settings' tab
4. Create session, uncheck the checkbox to disable state.
5. Activate your changes.

12c Steps:

1. Login to the OSB domain EM console. http://hostname:port/em
2. On the left Navigation tab, under SOA click on the service-bus








3. On the service-bus page click on 'Operations' tab.
4. Search for the Proxy service
5. Uncheck the box under State column



6. Apply
7. Test


Helpful? Please Comment.

Happy Learning!!