High Availability with File/FTP adapter

High availability in B2B is typically achieved by running muliple instance of B2B pointing to the same metadata repository, front ended by a load balancer such as web cache or any hardware load balancer. Always HA using File/FTP transport is very challenging due to the non transactional nature of the transport. We have come up with two properties to handle the same.

1. oracle.tip.adapter.b2b.inHAMode= true
2. oracle.tip.adapter.b2b.HAInstanceName=MyHost

Note that the setting for oracle.tip.adapter.b2b.HAInstanceName must be unique among the B2B instances using the same B2B repository.This is followed by running the script against b2b schema.

This feature allows the File/FTP to automatically detect which instance should poll and when the first instance stop polling (due to outages), the second instance will start polling by registering itself in the B2B_HA_REGISTRY after detecting the first instance is down. Even if there is a restart of the first instance it will not poll as the second instance is registered and active and acts as a Fail over instance, ready to take over in case of issue with second instance.
P.S

1. Please ensure to be on 10.1.2.3 patch.
2. Do not create the table manually and insert the instance related information, it should happen on its own if the patch is functional.
3. Need B2B restart after adding the above properties to tip.properties.

Large EDI File Processing

This challenge is addressed by writing the payload to a input directory. The corresponding translated payload will also be written to an output directory.

p.s As a pre-requisite always apply the latest patch and set the appropriate heap size as per the performance best practice post.

1. Set the heap size as discussed in the peformance post.
2. Apply the latest patch.
3. You will need to set following two properties in tip.properties

1) oracle.tip.adapter.b2b.edi.incoming.wiremessage.size
.
Specify the size of incoming EDI message that must be treated as large enough
to be kept in file system instead of memory, during message processing. The size
specified is in bytes.

Default is 300 MB (300000000)

2) oracle.tip.adapter.b2b.edi.incoming.wiremessage.directory
Specify directory where large incoming message must be saved.
Example:
oracle.tip.adapter.b2b.edi.incoming.wiremessage.directory=/scratch/mdsharma/edi_files_dir/globalchips

4. For outbound consider File batching as well as Disk caching.

These are the parameters needed to set for this in tip.properties file -

# entries to support large file outbound processing
oracle.tip.adapter.b2b.edi.fileBased=true
oracle.tip.adapter.b2b.edi.outputDirectory=E:\\oracle\\product\\DVAPPSRV01\\ip\\log\\edioutput
#outputSize is expressed in bytes
oracle.tip.adapter.b2b.edi.outputSize=102400

#entries to support no-lock processing of batched outbound messages
oracle.tip.adapter.b2b.sqltablelock=false

#entries to support splitting large batched outbound into smaller batches
#value determines size of smaller batches split off from the large batch
#if this property exists and is set to a value, then #oracle.tip.adapter.b2b.edi.outputDirectory
#and oracle.tip.adapter.b2b.edi.outputSize must be specified.
#if this property exists and is set to a value, oracle.tip.adapter.b2b.edi.fileBased #can be either true or false. true is preferred.
oracle.tip.adapter.b2b.edi.mergeMsgSize=500
oracle.tip.adapter.b2b.qMsgRatio=20

#Entry for file-based processing across multiple B2B instances.
oracle.tip.adapter.b2b.edi.fileBased.directory=E:\\Oracle\\Product\\DVAPPSRV01\\ip\\log\\filebased.

Variable Retry Interval for HTTP Transport

Use case : There is a notion of Retry Count and Time to Acknowledgement in Oracle B2B for HTTP Transport where by B2B Engine retries for a Retry Count number of times with an interval of Time to Acknowedgement between every retries. Consider a practical case where in Partner server is down and it takes few hours to bring it up, hence it may not be practical to retry it immediately.

Details :

Using the Variable Retry Interval it is possible to schedule the retry activity during appropriate time. This will make the retry feature more effective.

To enable this feature set

oracle.tip.transport.HttpSender.TimeToAck = 1,20,120

where it will retry after 1 minute, 20 minute and 2 hour after previous retries.

Stacking Feature in B2B to handle the scheduled outage of Trading Partner

Use case

1. Should be able to configure the scheduled outage of a TP on the host.
2. During the outage, B2B should be able to store the messages without any processing and not error them out.
3. At the end of outage should be able to send the messages to TP in a controlled manner i.e batch mode. The batches can be defined either using message id or time range or it can be partner-wise

This Use case is handled by Quesing all the appropriate Agreement related to the Trading partner during the begging of the down time and is done by using public API.

java oracle.tip.configuration.ConfigurationManager -quiesce

and to reactivate the configuration at the end of Scheduled down time.

java oracle.tip.configuration.ConfigurationManager -reactivate

Resubmit :

InstanceMessageUtil is enhanced to get the instance messages based on Start time, End time , Agreement Name and status.

getInstanceMessages(String startDateStr,String endDateStr,
String agrmtName,String status)

This will provide all the messageID and the resubmission utility can be used in manual mode to resubmit all the messages.

Please note In case of a planned outage of the trading Partner, you can use the Stacking feature mentioned above, in which case B2B will not post the message to the Trading partner end point. If it is not a planned outage, it errors out in the transport layer


and you can use B2B in Auto/Manual mode to resubmit. HTH. Let us know.

Resubmission Feature

Resubmission feature which is part of the latest patch.

Introduction

Oracle AS B2B is a B2B Product with very rich protocol stack and is based on Standard based Scalable Architecture managed through Oracle Application server. This product has a rich Exception handling framework to capture the error/Exception at various stages in the Engine, and send the exception message to IP_IN_QUEUE with B2BERRORUSER. With the increased customer base over the recent past, resubmission of error/Exception message in B2B is the key feature identified to be supported. There have been many best practices used by several of our customer to get the Exception message and to resubmit the business message using the Workflow driven BPEL Process. This is just an initial pilot project undertaken to provide the Resubmission feature out of the box. It is expected to go for multiple enhancements depending on the customer drive and the acceptance.

Use Case Addressed

1. Basic Resubmission feature with Retry count and Interval for both inbound and outbound.
2. Notification to B2B Administrator.
3. Resubmission based on message ID, Agreement and Status.
4. Payload based resubmission. This is ideally for error/Exception based on payload.
5. Outbound resubmission using IP_OUT_QUEUE and inbound Resubmission through Event queue. This will get the inbound message goes through all the layer of B2B as if it has come from Trading Partner.
6. Deletion of duplication message and correlation of business message with appropriate Acknowledgement.
7. Support Stacking feature to handle the B2B Downtime and Resubmission after the same.
8. Variable Resubmission interval.

Outbound Scenario
B2Bresubmit Utility runs in two modes.

Auto Mode:
B2Bresubmit Utility runs in infinite listening mode to IP_IN_QUEUE with B2BERRORUSER. For every exception message, it gets the messageID and uses InstanceMessageUtil to obtain the From Party, To Party, DocType , Revision and the payload . It uses the above information to enque the message to IP_OUT_QUEUE to be picked up by B2B.

Depending on the configured Retry Count and Interval it resubmit the message and send a notification to the configured email ID once after exhausting all the attempt to resubmit the message. Email subject contain the messageID and the body contain Error Description.


Variable Resubmission Interval

Be default the Retry Interval is constant for all the retry effort during resubmission. However there is an option to define variable resubmission Interval for every resubmission. This will enable the B2BAdministrator enough time to debug and bring up the partner server in case of any issues.

If the value for ResubmitWithInterval is set to true, the utility will resubmit every message with interval mentioned for the property

oracle.tip.adapter.b2b.data.ReSubmit.ResubmitIntervals.


In this example,

First resubmission will happen after 1 minutes of first failure
Second resubmission will happen after 1 minutes of first resubmission

Also ensure that the value for oracle.tip.adapter.b2b.data.ReSubmit.ReSubmitCount is same as number of intervals mentioned.
Manual Mode
B2Bresubmit utility resubmits messages based on
1. Message ID,
2. Agreement ID and Status.

MessageId based
Once after B2BAdministrator gets the notification for a failed resubmission, he will extract the messageID from the email, Identify the root cause of the problem by referring b2b.log/Report, fix the problem and use Resubmission utility in manual mode to resubmit the message based on messageID.
Agreement name and message status

Ideally this feature is used in Bulk Resubmission after the Trading partner Downtime and is based on Agreement name, Status, Start time and End time.

The typical way to execute is as below.

Example:

java oracle.tip.adapter.b2b.data.ReSubmit "2008/01/28 16:00" "2008/01/28 16:15" Agreement Error

The time format is: yyyy/MM/dd HH24:MI

Inbound Scenario

Inbound Resubmission is pretty much the same as Outbound with both Auto and Manual mode, however the resubmission is based on the event queue, which will enable the resubmission messages to go through the respective exchange layer as if it has come from Trading Partner.

Resubmission Configuration

Complete List of configurations used for this utility