Integration Design Pattern – Synchronous Facade for Asynchronous Interaction

Introduction In this blog, we will explore a Hybrid Message Interaction pattern, which combines the characteristics of traditional Synchronous Request-Reply and Asynchronous patterns. We will also see, the need for such a design pattern and how it can be implemented using Oracle SOA Suite. Need for this Design Pattern A Hybrid Synchronous-Asynchronous message exchange pattern […]

Oracle HCM Cloud – Bulk Integration Automation Using SOA Cloud Service

Introduction Oracle Human Capital Management (HCM) Cloud provides a comprehensive set of tools, templates, and pre-packaged integration to cover various scenarios using modern and efficient technologies. One of the patterns is the batch integration to load and extract data to and from the HCM cloud. HCM provides the following bulk integration interfaces and tools: HCM Data […]

Fusion HCM Cloud Bulk Integration Automation

Introduction Fusion HCM Cloud provides a comprehensive set of tools, templates, and pre-packaged integration to cover various scenarios using modern and efficient technologies. One of the patterns is the bulk integration to load and extract data to/from cloud. The inbound tool is the File Based data loader (FBL) evolving into HCM Data Loaders (HDL). HDL […]

Fusion Applications WebCenter Content Integration – Automating File Import/Export

Introduction Oracle WebCenter Content, a component of Fusion Middleware, is a strategic solution for the management, security, and distribution of unstructured content such as documents, spreadsheets, presentations, and video. Oracle Fusion Applications leverages Oracle WebCenter Content to store all marketing collateral as well as all attachments. Import flow also uses it to stage the CSV files […]

Methods for Resubmitting Imaging Documents to SOA Workflow

When a document is created or uploaded in WebCenter Imaging, if a workflow connection exists the Imaging managed server automatically attempts to inject the document into workflow. However, in scenarios where either the SOA instance is down or another error causes a workflow injection failure, the workflow never gets started. If an error occurs, the […]

Custom Message Data Encryption of Payload in SOA 11g

Introduction This article explains how to encrypt sensitive data (such as ssn, credit card number, etc ) in the incoming payload and decrypt the data back to clear text (or original form) in the outgoing message. The purpose is to hide the sensitive data in the payload, in the audit trail, console and logs. Main […]

How to Recover Initial Messages (Payload) from SOA Audit for Mediator and BPEL components

Introduction In Fusion Applications, the status of SOA composite instances are either running, completed, faulted or staled. The composite instances become staled immediately (irrespective of current status) when the respective composite is redeployed with the same version. The messages (payload) are stored in SOA audit tables until they are purged. The users can go through Enterprise […]

How to emulate 10g Adapter start/stop behaviour by manipulating the InboundThreadCount parameter

Introduction In 10g, there was a mechanism for suppressing consumption of messages at the Adapter level. That mechanism can not be used in 11g. But there is a way… Main Article The way to do this is to set the InboundThreadCount in the appropriate MBean to zero. This will effectively suppress consumption of messages – […]

OIM 11g R2 Delegated Administration Model – Sample implementation (Part I)

Introduction It is a very common requirement from customers to have a delegated administration model that is not tied to the organizations where the administrators are placed. Historically, OIM only supports a one-to-one relationship between Users and Organizations. However, starting with OIM 11g R2 and the introduction of the Catalog, it is possible to publish resources […]

Part 3: Kerberos Authentication, RBAC and SAML Identity Propagation in OAG

Introduction This post is the third one of a series by Andre Correa and Paulo Pereira on OAG (Oracle API Gateway). In the first post we introduced the use case and talked about the Kerberos authentication part. In the second post we talked about Role Based Access Control. In this one we describe how to […]

EDN Debugging

I have a customer asked me about how to debug EDN. This blog will show you how to debug EDN and the tools that can be used to debug EDN.

<!–[if !supportLists]–>1.<!–[endif]–>Using EDN-DB-LOG

EDN comes with a useful EDN DB logging servlet to view logging information generated by the EDN component. It is only available for END-DB which is based on AQ, it will not work for EDN with JMS. The servlet uses a table called “EDN_LOG_MESSAGES” in SOA_INFRA schema. It logs the operation on “main” operation of event_queue and oaoo-queue with timestamp information.

The default URL is http://<host_name>:<port_number>/soa-infra/events/edn-db-log.  In this servlet, you can enable, disable and clear logs but you need to have the administrative role in order to access the servlet.  This is a good tool to use to display dynamic counts of un-deq’ed events (potentially “stuck”) in the “main” and “OAOO” queues. The log also provides information of EDN bus when it is being connected to AQ-DB.  In the screenshot below, “EVENT_SEQ:202” shows that the EDN bus is being started.

When the logging is enabled, the EDN_LOG_MESSAGES table will be populated with messages until the logging is disabled, so it is inadvisable to leave logging turned on for large amounts of events. It is recommended to clear the log regularly.

Messages in the log are grouped together. Usually the first line in the group will indicate what operation is being performed, and the event sequence number is used to group the messages together and each group will be highlighted using the same color (e.g. enqueuing an event or handling an event that has been dequeued). In the screenshots below, “EVENT_SEQ:204” is dequeuing an event and “EVENT_SEQ:205” is enqueuing an event.


2. Database tables

The second method is to examine the database table. You can check on count of potentially “stuck” events currently in the following queue tables:


  • EDN_EVENT_QUEUE_TABLE – This table is for “EDN_EVENT_QUEUE” AQ. Every event published is temporarily enqueued into this table.
  • EDN_OAOO_DELIVERY_TABLE – This table only stores the event with “OAOO” (one-and-only-one) delivery target(s). The event is temporarily enqueued into this table for END_OAOO_QUEUE AQ.


For event with OAOO delivery target, it travels through both tables, first it is stored in EDN_EVENT_QUEUE_TABLE and then in EDN_OAOO_DELIVERY_TABLE.

This example shows the event enq’ed in “edn_event_queue”.


Another alternative is to check the count from the following database views:


  • AQ$EDN_EVENT_QUEUE_TABLE: There are two rows for every event enqueued into “edn_event_queue”.
  • AQ$EDN_OAOO_DELIVERY_TABLE: There is one row for every event enqueued into “edn_oaoo_queue”. 



This example shows further details about that event which is deq’ed by the subscribers of “edn_event_queue”.


The AQ$EDN_EVENT_QUEUE_TABLE.MSG_STATE shows the state of the message.  The states are listed in the table below:

State Code










The message is ready to be processed, i.e., either the delay
time of the message has passed or the message did not have a delay time specified






The delay specified by message_properties_t.delay while executing dbms_aq.enqueue has not been reached.






The message has been successfully processed (dequeued) but will remain in the queue until the retention_time specified for the queue while executing dbms_aqadm.create_queue has been reached.






The message was not successfully processed (dequeued) in either 1) the time specified by message_properties_t.expiration while executing dbms_aq.enqueue or 2) the maximum number of dequeue attempts (max_retries) specified for the queue while executing dbms_aqadm.create_queue.






Buffered messages enqueued by a Streams Capture process




Buffered Expired


User-enqueued expired buffered messages




If the subscriber type is equal to 2 when there is no subscribers to the message, and there is no transaction id due to invalid transaction, it will be marked as UNDELIVERABLE.



When the state message is expired, the AQ$EDN_EVENT_QUEUE_TABLE.EXPIRATION_REASON will be populated with one of the following value:


  • Messages to be cleaned up later



3.<!–[endif]–>Server Logs


The third method is using EM log configuration and log viewer. There are few logger names related the EDN:


  • oracle.integration.platform.blocks.event
  • oracle.integration.platform.blocks.event
  • oracle.integration.platform.blocks.event.saq
  • oracle.integration.platform.blocks.event.jms

You can set log level to one of the following to capture more details:

  • TRACE:1 (FINE) – Logging the event content details, XPath filter results, event enqueue, dequeue, publish and send operations
  • TRACE:16 (FINER) – Logging the begin, commit and rollback statements of XA transaction (for OAOO) and retry count.
  • TRACE:32 (FINEST)  – All above.

The log level changes take effect immediately without server restart.However, if you want the changes to persist after server restart, make sure to check on the “Persist Log Level State Across Component Restarts” prior to server restart.


At FINER or FINEST level, you may see loggings like “Began XA for OAOO.” and “Rolled back XA for OAOO.” These are normal messages of OAOO event delivery when there are no events waiting to be delivered. They are NOT errorred conditions. You may turn off these messages by setting the Java logging level to “TRACE:1 (FINE)” or a higher value. All detailed logging goes into SOA server’s diagnostic.log file configured in EM.  Below is a snippet of the diagnostic log showing the event delivery to an OAOO subscriber:


[SRC_METHOD: finerBeganXA] Began XA for OAOO.


[SRC_METHOD: fineEventPublished] Received event: Subject: … Sender: …. Event: …


[SRC_METHOD: fineFilterResults] Filter [XPath Filter: …] for subscriber “…” returned true/false


[SRC_METHOD: fineDequeuedEvent] Dequeued event, Subject: … [source type ..]: business-event…


[SRC_METHOD: fineOAOOEnqueuedEvent] Enqueued OAOO event, Subject: … [source: …, target: … ]: business-event…


[SRC_METHOD: fineOAOODequeuedEvent] Dequeued OAOO event, Subject: … [source: …, target: …]: business-event…


[SRC_METHOD: finerInsertedTryCount] Inserted try count for msgId: …. Status: …


[SRC_METHOD: finerRemovedTryCount] Removed try count for msgId: …


[SRC_METHOD: fineSentOAOOEvent] Sent OAOO event [QName: … to target: …]: business-event…


[SRC_METHOD: fineCommittedOAOODelivery] Committed OAOO Delivery, Subject: … [source: …, target: …]: business-event…


[SRC_METHOD: finerBeganXA] Began XA for OAOO.


[SRC_METHOD: finerRolledbackXA] Rolled back XA for OAOO.


In some cases, more than one method may be necessary to assist in the debugging process. Below is a comparison of server and DB logging that might help you in evaluating and determining which method(s) is/are most suitable in your environment.




Server Logging

  • EDN will generate standard Java logging messages when events are published, when they are pulled from persistent storage and when they are delivered.
  • The logger used by EDN depends on the implementation. For instance, EDN-DB uses “oracle.integration.platform.blocks.event.saq” and EDN-JMS uses “oracle.integration.platform.blocks.event.jms”.
  • As in all Java logging, messages are written at different log levels from ERROR to FINEST. The most detailed messages (including the event body) use FINEST.
  • Loggers can also be configured in logging.xml in your config directory.




DB Logging

  • If you are using EDN-DB, a lot of debugging information may not be accessible due to the many activities that occurred in the database which couldn’t be logged in the server. Hence, a servlet web page that accesses the debug logging table is implemented to assist the debugging process. The page is located at: http://hostname:port/soa-infra/events/edn-db-log and you do need to have administrative role to access the servlet page.
  • There are commands on the servlet web page to enable and disable logging and for clearing the log table. The table will be filled with messages, so it is inadvisable to leave logging turned on for large amounts of events. It is recommended to clear the log regularly.
  • Messages in the log are grouped together. Usually the first line in the group will indicate what operation is being performed (e.g. enqueuing an event or handling an event that has been dequeued).

<!–[if !supportLists]–>


Mediator Instance Tracking


Mediator supports three modes for instance tracking by changing the audit level in EM->SOA->SOA-INFRA->SOA Administration->Mediator Properties:


  1. Off – No instance tracking for successfully completed instance, however, instances and faulted instances are created even in this mode.  Audit trail will not be created with this flag.
  2. Production – Instance tracking is enabled for all.  All audit details are logged, except the details of assign activities, but the instances and payloads are not captured.
  3. Development – Instance tracking is enabled for all.  All audit details are logged, and the instances and payloads are also captured.


The following tables are used by Mediator to store the instance and audit trail data:


  1. MEDIATOR_INSTANCE – This table contains one row for each mediator instance. Each instance has a unique id. It stores ecid, composite instance id and parent component id from normalized message and overall state of an instance in the component_state column.  The component state depends on the combination of the mediator case instance states, the states are listed here.
  2. MEDIATOR_CASE_INSTANCE – This table contains one row for each mediator routing rule and fault information for a routing rule is also stored.  Each case instance has one unique id.  It stores mediator instance id and case name, related fault information and information pertaining to retries.  This is the base table for executing automatic retries using fault policies.
  3. MEDIATOR_CASE_DETAIL – This table contains multiple rows for each routing rule and stores mediator audit trail xml as a blob for each routing rule. Each case detail rows are bound together by case id.  It stores case detail state, audit trail for each case detail.  The state of the latest case detail is the current state of the case.
  4. MEDIATOR_AUDIT_DOCUMENT- This table stores payload at each stage of mediator message flow and payloads are stored only when instance tracking audit level is set to “Development”. Each row in this table stores the payload at a point in the message flow. e,g, transformed payload, payload being sent to the target service.

Below is a screenshot of a basic mediator project with 2 routing rules which polls an xml file from an input folder, transforms the content and writes the xml file to a folder. 

When the mediator receives a massage, it creates a mediator instance, and then depending on the number of routing rule, one or more case instance will be created in the MEDIATOR CASE INSTANCE table. The engine will then initializes the audit trail xml and stores it as an XML document. After each processing point (e.g. transformation, filter evaluation etc), it stores the trail messages to audit trail xml and persists to audit trail table (MEDIATOR_CASE_DETAIL.AUDIT_TRAIL  and/or MEDIATOR_AUDIT_DOCUMENT), then the mediator instance state will be updated.

1. When the mediator instance kicks off, a composite instance will be created in the COMPOSITE_INSTANCE table, and unique ECID will be assigned to the instance.


select * from composite_instance where ecid=’1b7e5955c26b51de:-56440391:13d41f410c6:-8000-000000000000144b’

2. Using ECID, you can retrieve the mediator instance data and the component state from the mediator instance table.  From this point onward, MEDIATOR_INSTANCE.ID will be used to retrieve the mediator case data.

select * from mediator_instance where ecid=’1b7e5955c26b51de:-56440391:13d41f410c6:-8000-000000000000144b’

 3. Depending on the number of routing rules, the mediator will store each routing rule separately in the MEDIATOR_CASE_INSTANCE table and the MEDIATOR_CASE_INSTANCE .ID will be used to retrieve the case detail for each routing rule.  In the above example, there are 2 routing rules.

select * from mediator_case_instance where instance_id = ‘C64B82E086BB11E2BFBE1B53FB1929E1’;

4. The audit trail of each routing rule is stored in the MEDIATOR_CASE_DETAIL table in compressed format.

select * from mediator_case_detail where instance_id = ‘C64B82E086BB11E2BFBE1B53FB1929E1’;


Below are the xml data that are stored in the MEDIATOR_CASE_DETAIL.AUDIT_TRAIL column.  In the example below, two routing rules were being executed. The first event routing rule’s result was equal to “false”, then the second routing rule was executed. The second event routing rule’s result was successful, subsequently the message was transformed and published to the destination. If you have the audit trail level set to “Development”, you can use the audit id in the case trail to retrieve the payload from the MEDIATOR_AUDIT_DOCUMENT table for further investigation.



  <event type=”inputPayloadReceived” status=”Completed”

         parentId=”C64B82E086BB11E2BFBE1B53FB1929E1″ date=”1362615182063″





CASE_ID= C66EE96086BB11E2BFBE1B53FB1929E1


  <event type=”case” id=”C66EE96086BB11E2BFBE1B53FB1929E1

         parentId=”C64B82E086BB11E2BFBE1B53FB1929E1″ caseName=”USCustomer.Write”

         date=”1362615182073″ auditId=”C64BA9F086BB11E2BFBE1B53FB1929E1″>



  <event type=”condition” status=”Completed”

         parentId=”C66EE96086BB11E2BFBE1B53FB1929E1″ date=”1362615182074″






CASE _ID= C670700086BB11E2BFBE1B53FB1929E1


  <event type=”case” id=”C670700086BB11E2BFBE1B53FB1929E1


         caseName=”CanadaCustomer.Write” date=”1362615182083″




  <event type=”condition” status=”Completed”

         parentId=”C670700086BB11E2BFBE1B53FB1929E1″ date=”1362615182083″




  <event type=”transform” status=”Completed”

         parentId=”C670700086BB11E2BFBE1B53FB1929E1″ date=”1362615182102″




  <event type=”publish” status=”Completed”

         parentId=”C670700086BB11E2BFBE1B53FB1929E1″ date=”1362615182124″

         auditId=”C67292E086BB11E2BFBE1B53FB1929E1″ parentRefId=”mediator:C64B82E086BB11E2BFBE1B53FB1929E1:C670700086BB11E2BFBE1B53FB1929E1:oneway”>





SOA Suite for Healthcare Integration startup errors due to expired passwords.

SOA Suite for Healthcare integration involves starting up the managed servers, which are in turn, dependent on valid connections to databases. In many low-maintenance environment like Virtualbox images distributed for training and worksh…

Oracle SOA for Healthcare – Setting Endpoint Acknowledgement Acceptance

Acknowledgment acceptance in SOA Suite for Healthcare is globally set through the console at the document level. Currently there is no way to override the global setting for an endpoint in the SOA for Healthcare console. The illustration below shows acknowledgment acceptance being set in the document type definition in the SOA for Healthcare console

B2B Agreement Life-Cycle Management, Part 1 – Best Practices for High Volume CPA Import Operations with ebXML


B2B 11g supports ebXML messaging protocol, where multiple CPAs can be imported via command-line utilities. 

This note highlights one aspect of the best practices for import of CPA, when large numbers of CPAs in the excess of several hundreds are required to be maintained within the B2B repository.


The import of CPA usually is a 2-step process, namely creating a file using b2bcpaimport utility based on a CPA properties file and then using b2bimport to import the b2b repository.  The commands are provided below:

  1. ant -f ant-b2b-util.xml b2bcpaimport -Dpropfile=”<Path to>” -Dstandard=true
  2. ant -f ant-b2b-util.xml b2bimport -Dlocalfile=true -Dexportfile=”<Path to>” -Doverwrite=true

Usually the first command completes fairly quickly regardless of the number of CPAs in the repository. However, as the number of trading partners within the repository goes up, the time to complete the second command could go up to ~30 secs per operation. So, this could add up to a significant amount, if there is a need to import hundreds of CPA in a production system within a limited downtime, maintenance window. 


In situations, where there is a large number of entries to be imported, it is best to setup a staging environment and go through the import operation of each individual CPA in an empty repository. Since, this will be done in an empty repository, the time taken for completion should be reasonable. 

After all the partner profiles have been imported, a full repository export can be taken to capture the metadata for all the entries in one file. 

If this single file with all the partner entries is imported in a loaded repository, the total time taken for import of all the CPAs should see a dramatic reduction.


Let us take a look at the numbers to see the benefit of this approach. With a pre-loaded repository of ~400 partners, the individual import time for each entry takes ~30 secs. So, if we had to import another 100 partners, the individual entries will take ~50 minutes (100 times ~30 secs). On the other hand, if we prepare the repository export file of the same 100 partners from a staging environment earlier, the import takes about ~5 mins.

The total processing time for the loading of metadata, specially in a production environment, can thus be shortened by almost a factor of 10.


The following diagram summarizes the entire approach and process.


The material posted here has been compiled with the help from B2B Engineering and Product Management teams.

Oracle B2B – Synchronous Request Reply

Beginning with Oracle SOA Suite PS5 (, B2B supports synchronous request reply over http using the b2b/syncreceiver servlet. I’m attaching a demo to this blog which includes a SOA composite archive that needs to be deployed using JDeveloper, a B2B repository with two agreements that need to be deployed using the B2B console, and a test xml file that gets sent to the b2b/syncreceiver servlet using your favorite SOAP test tool

How to Achieve OC4J RMI Load Balancing

This is an old, Oracle SOA and OC4J 10G topic. In fact this is not even a SOA topic per se. Questions of RMI load balancing arise when you developed custom web applications accessing human tasks running off a remote SOA 10G cluster. Having returned from a customer who faced challenges with OC4J RMI load balancing, I felt there is still some confusions in the field how OC4J RMI load balancing work. Hence I decide to dust off an old tech note that I wrote a few years back and share it with the general public.

Here is the tech note:


A typical use case in Oracle SOA is that you are building web based, custom human tasks UI that will interact with the task services housed in a remote BPEL 10G cluster. Or, in a more generic way, you are just building a web based application in Java that needs to interact with the EJBs in a remote OC4J cluster. In either case, you are talking to an OC4J cluster as RMI client. Then immediately you must ask yourself the following questions:

1. How do I make sure that the web application, as an RMI client, even distribute its load against all the nodes in the remote OC4J cluster?

2. How do I make sure that the web application, as an RMI client, is resilient to the node failures in the remote OC4J cluster, so that in the unlikely case when one of the remote OC4J nodes fail, my web application will continue to function?

That is the topic of how to achieve load balancing with OC4J RMI client.


You need to configure and code RMI load balancing in two places:

1. Provider URL can be specified with a comma separated list of URLs, so that the initial lookup will land to one of the available URLs.

2. Choose a proper value for the oracle.j2ee.rmi.loadBalance property, which, along side with the PROVIDER_URL property, is one of the JNDI properties passed to the JNDI lookup.(

More details below:


The JNDI property’s job is, when the client looks up for a new context at the very first time in the client session, to provide a list of RMI context

The value of the JNDI property goes by the format of a single URL, or a comma separate list of URLs.

  • A single URL. For example: opmn:ormi://host1:6003:oc4j_instance1/appName1
  • A comma separated list of multiple URLs. For examples:  opmn:ormi://host1:6003:oc4j_instanc1/appName, opmn:ormi://host2:6003:oc4j_instance1/appName, opmn:ormi://host3:6003:oc4j_instance1/appName

When the client looks up for a new Context the very first time in the client session, it sends a query against the OPMN referenced by the provider URL. The OPMN host and port specifies the destination of such query, and the OC4J instance name and appName are actually the “where clause” of the query.

When the PROVIDER URL reference a single OPMN server

Let’s consider the case when the provider url only reference a single OPMN server of the destination cluster. In this case, that single OPMN server receives the query and returns a list of the qualified Contexts from all OC4Js within the cluster, even though there is a single OPMN server in the provider URL. A context represent a particular starting point at a particular server for subsequent object lookup.

For example, if the URL is opmn:ormi://host1:6003:oc4j_instance1/appName, then, OPMN will return the following contexts:

  • appName on oc4j_instance1 on host1
  • appName on oc4j_instance1 on host2,
  • appName on oc4j_instance1 on host3, 

(provided that host1, host2, host3 are all in the same cluster)

Please note that

  • One OPMN will be sufficient to find the list of all contexts from the entire cluster that satisfy the JNDI lookup query. You can do an experiment by shutting down appName on host1, and observe that OPMN on host1 will still be able to return you appname on host2 and appName on host3.

When the PROVIDER URL reference a comma separated list of multiple OPMN servers

When the JNDI propery java.naming.provider.url references a comma separated list of multiple URLs, the lookup will return the exact same things as with the single OPMN server: a list of qualified Contexts from the cluster.

The purpose of having multiple OPMN servers is to provide high availability in the initial context creation, such that if OPMN at host1 is unavailable, client will try the lookup via OPMN on host2, and so on. After the initial lookup returns and cache a list of contexts, the JNDI URL(s) are no longer used in the same client session. That explains why removing the 3rd URL from the list of JNDI URLs will not stop the client from getting the EJB on the 3rd server.

About the oracle.j2ee.rmi.loadBalance Property

After the client acquires the list of contexts, it will cache it at the client side as “list of available RMI contexts”.  This list includes all the servers in the destination cluster. This list will stay in the cache until the client session (JVM) ends. The RMI load balancing against the destination cluster is happening at the client side, as the client is switching between the members of the list.

Whether and how often the client will fresh the Context from the list of Context is based on the value of the  oracle.j2ee.rmi.loadBalance. The documentation at list all the available values for the oracle.j2ee.rmi.loadBalance.

Value Description
client If specified, the client interacts with the OC4J process that was initially chosen at the first lookup for the entire conversation.
context Used for a Web client (servlet or JSP) that will access EJBs in a clustered OC4J environment.
If specified, a new Context object for a randomly-selected OC4J instance will be returned each time InitialContext() is invoked.
lookup Used for a standalone client that will access EJBs in a clustered OC4J environment.
If specified, a new Context object for a randomly-selected OC4J instance will be created each time the client calls Context.lookup().

Please note the regardless of the setting of oracle.j2ee.rmi.loadBalance property, the “refresh” only occurs at the client. The client can only choose from the “list of available context” that was returned and cached from the very first lookup. That is, the client will merely get a new Context object from the “list of available RMI contexts” from the cache at the client side. The client will NOT go to the OPMN server again to get the list. That also implies that if you are adding a node to the server cluster AFTER the client’s initial lookup, the client would not know it because neither the server nor the client will initiate a refresh of the “list of available servers” to reflect the new node.

About High Availability (i.e. Resilience Against Node Failure of Remote OC4J Cluster)

What we have discussed above is about load balancing. Let’s also discuss high availability.

This is how the High Availability works in RMI: when the client use the context but get an exception such as socket is closed, it knows that the server referenced by that Context is problematic and will try to get another unused Context from the “list of available contexts”. Again, this list is the list that was returned and cached at the very first lookup in the entire client session.

A review of Oracle SOA Suite 11g Administrator’s Handbook

Highly recommended, a tour de force. Packt’s new Oracle SOA Suite 11g Administrator’s Handbook by Ahmed Aboulnaga and Arun Pareek is packed full of essential information for the Oracle SOA administrator, in fact I would go so far as to … Continue reading

Reading Oracle SOA Suite 11g Administrator’s Handbook

I am reading the new Oracle SOA Suite 11g Administrator’s Handbook by Ahmed Aboulnaga and Arun Pareek.  I am half way through it and I have to say – it is just great!  Will post some detailed comments soon!

BPM 11g – Dynamic Task Assignment with Multi-level Organization Units

I’ve seen several requirements to have a more granular level of task assignment in BPM 11g based on some value in the data passed to the process. Parametric Roles is normally the first port of call to try to satisfy this requirement, but in this blog we will show how a lot of use-cases can be satisfied by the easier to implement and flexible Organization Unit.