Oracle B2B Protection from Failures and Expected Behavior

Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-47 Figure 5–26 Oracle B2B Request Flow

5.7.1.4 Oracle B2B Configuration Artifacts

You can enable and disable metrics for Oracle B2Bs Server using Oracle Enterprise Manager Fusion Middleware Control. This is the only property directly exposed by Oracle Enterprise Manager Fusion Middleware Control. The configuration for Oracle B2Bs Server is maintained in the SOA database and most of it is exposed by the Oracle B2B user interface application. For details about Oracle B2B configuration, see the Oracle Fusion Middleware User’s Guide for Oracle B2B.

5.7.2 Oracle B2B High Availability Architecture and Failover Considerations

Figure 5–6 describes a two-node Oracle SOA Service Infrastructure cluster running on two WebLogic Servers. Oracle B2B is deployed as part of the Oracle SOA Service infrastructure composite application. The following high availability characteristics are specific to an Oracle B2B high availability deployment: ■ The Oracle B2B user interface application runs inside each one of Oracle WebLogic Server servers, and as part of the same cluster as the Oracle SOA Service Infrastructure application. ■ Oracle B2B’s server maintains the partners, documents, and channels definitions in the SOA database using an Oracle RAC database.

5.7.2.1 Oracle B2B Protection from Failures and Expected Behavior

This section describes how an Oracle B2B high availability cluster deployment protects components from failure and the expected behavior if component failure occurs. Oracle B2B UI Failure The Oracle B2B user interface application maintains some navigation information in memory. When a failure occurs in one of the managed servers running the Oracle B2B user interface, users requests are redirected to another active WebLogic Server running the application. Ongoing requests from Oracle HTTP Server time out according the time out setting in Oracle HTTP Server’s configuration. Failover requires those users accessing the failed instance to log in again, since the application is not enabled for serializing the session information. The Oracle B2B user interface in-memory data is non-transactional, and some steps may need to be revisited in the case of failover. For general information about Oracle SOA Service Infrastructure process failure, see Section 5.2.2.1, Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior Start SOA Infrastructure Start B2B Initialization of Event Listeners Wait for Requests from Channels Insert request in JMS queue B2B Event listener process message Insert message in DB 5-48 Oracle Fusion Middleware High Availability Guide Node Failure If a node failure occurs, or if the local Oracle WebLogic Server Node Manager reaches the maximum restart tries on the failed managed server, whole server migration is triggered after the available server verifies the time stamp in the database leasing system. The other Oracle B2B engine remains available for processing new messages from the different channels. At the same time, the remaining Oracle B2B server should resume the pending operations for singleton channels, such as FTP, email, or file, after the default timeout period is reached in the time stamp the failed node sets in the database two minutes by default. For Oracle B2B’s User Interface application, ongoing requests from Oracle HTTP Server time out according to Oracle HTTP Server configuration. Database Failure For information about Oracle B2B database failure, see Section 5.2.2.1, Oracle SOA Service Infrastructure Protection from Failures and Expected Behavior

5.7.2.2 Oracle B2B Cluster-Wide Configuration Changes