Troubleshooting Oracle Human Workflow High Availability

5-44 Oracle Fusion Middleware High Availability Guide ■ Application name ■ Host name ■ HTTP port ■ HTTPS port optional ■ URI

5. Click Apply.

5.6.2 Oracle Human Workflow High Availability Architecture and Failover Considerations

Figure 5–6 describes a two-node Oracle SOA Service Infrastructure cluster running on two WebLogic Servers. Oracle Human Workflow is deployed as part of the Oracle SOA Service infrastructure composite application.

5.6.2.1 Oracle Human Workflow Protection from Failures and Expected Behavior

Oracle Human Workflow’s engine uses transactional EJBs for persistence and JMS queues for user notification. All state is stored in the database and the JMS queue, and there is no in-memory session state to be replicated for recovery. Therefore, Oracle Human Workflow’s service engine and the associated Java EE applications are run in an active-active topology on a WebLogic cluster. In the case of a server or hardware crash, whole server migration must be configured for recovering pending transactions and JMS messages stored on the local queue. Notifications are not sent out until the server is restarted.

5.6.2.2 Manual Recovery Required for Human Workflow Task in Rejected MSG Table

The FabricInstanceManager.persistCompositeInstanceBean API or other InstanceManager APIs does not have built-in retry logic. When there are transient failures caused by Oracle RAC failover, the WS invocation is rejected directly. This manual recovery of these rejected messages is done using Oracle Enterprise Manager Fusion Middleware Control. To manually recover the rejected messages, in the Oracle Enterprise Manager Fusion Middleware Control, select SOA, soa-infrasoa_server1, composite_name, Faults and Rejected Messages , select the message, and choose Recover With Options. This causes the workflow request to be retried.

5.6.3 Troubleshooting Oracle Human Workflow High Availability

Human Workflow works like a standard Java EE application with a browser based client. Once a message is persisted to its runtime schema, it can be processed using the workflow UIs. If a server crashes in the middle of the transaction, you must recover the server for successful recovery or rollback. The following logs are relevant for debugging errors associated with Oracle Human Workflow: ■ oracle.soa.services.common ■ oracle.soa.services.notification ■ oracle.soa.services.workflow ■ oracle.soa.services.workflow.common ■ oracle.soa.services.workflow.evidence Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-45 ■ oracle.soa.services.workflow.metadata ■ oracle.soa.services.workflow.persistency ■ oracle.soa.services.workflow.query ■ oracle.soa.services.workflow.runtimeconfig ■ oracle.soa.services.workflow.soa ■ oracle.soa.services.workflow.task ■ oracle.soa.services.workflow.task.dispatch ■ oracle.soa.services.workflow.task.routing

5.7 Oracle B2B and High Availability Concepts

The information in this section guides you through the issues and considerations necessary for configuring Oracle B2B for high availability.

5.7.1 Oracle B2B Single-Instance Characteristics

Oracle B2B connects SOA composite applications to external services, applications, and technologies. Oracle B2B offers a multi-protocol gateway that supports industry-recognized B2B standards. Oracle B2B extends Oracle SOA Suite with business protocol standards, such as electronic data interchange EDI, ebXML, HL7, and RosettaNet. For details about Oracle B2Bs functionality, see the Oracle Fusion Middleware Administrator’s Guide for Oracle SOA Suite. Oracle B2B is a binding component within SOA Service Infrastructure. B2B metadata consists of trading partner details along with their supported documents and delivery channels which is stored within the MDS repository. The SOA composite has a reference to this metadata. Oracle B2B receives messages from different channels. A listener thread logs the messages in a table in the SOA database and sends the corresponding events to a JMS queue. Event handlers listen for events to process the requests in the JMS queues. Oracle B2B supports the following transport protocols for communication with business entities: ■ HTTPS ■ Oracle Advanced Queue ■ Email SMTP 1.0, IMAP 1.0, POP3 ■ File ■ FTP and SFTP SSH FTP ■ TCPIP ■ JMS For HTTP protocol, Oracle B2B uses the systems HTTP listener. For FTP and Email, Oracle B2B uses the external FTP and email server configured in the system. Even in high availability mode, only one B2B instance polls for incoming message for FTP, File, and email protocols. Note: MLLP TCPIP protocols are not supported in a clustered environment.