Apart from the capability of Handling XML file and Traditional EDI file based on various XML and EDI Standard, Oracle AS B2B also provides an option to Handle positional Flat File.
In 10.1.2.0.2 Positional EDI Document can be processed using Custom Document Plugin and following are the steps for the same.
1. Apply the latest B2B patch on 10.1.2.0.2 Installation.
2. Add the parser into registryValidator.xml
<Item
Name="SchemaFile">D:/Oracle/midtier/ip/oem/edifecs/XEngine/config/schema/IDoc_parser_40_2_char_delim.ecs</Item>
For EANCOM Based positional Flat file
There is a need to edit the registryValidator.xml to include the EANCOM parser schema. Open the eancom.ecs file that you have generated using B2B Document Editor in step 3 and Goto Tools->Generate Parser Schema. Save the parser schema for this eancom.ecs file as eancomparser.ecs . Copy this file to ORACLE_HOME/ip/oem/edifecs/XEngine/config/schema directory. Then edit $ORACLE_HOME/ip/oem/edifecs/XEngine/config/registryValidator.xml to include this eancomparser.ecs. For example,
<Item Name="SchemaFile">$ORACLE_HOME/ip/oem/edifecs/XEngine/config/schema/eancomparser.ecs</Item>
3. Design the ecs file in spec builder depending on the Positional Flat file.
4. As part of Document protocol Revision Override the Document Protocol parameter by specifying the ImplementationClass as oracle.tip.adapter.b2b.document.custom.CustomIDocumentPlugin
5. Provide the IDOC Ecs file as part of the Document definition Parameter along with start position and End position.
6. Run the End to End test.
Friday, August 31, 2007
Handling Positional Flat file
Posted by Ramesh Nittur at 7:08 PM 2 comments
Labels: B2B Document Editor, Custom, Positional Flat File
Wednesday, August 29, 2007
Typical EDI Errors and Solutions
Typical EDI Errors
1. Unable to identify the Document
Make sure the document protocol parameters defined in the document definition matches the corresponding data in the inbound document.
2. Agreement Identification which involves Document Identification and TP Identification
For e.g. trading partner agreement not found for the given input values: From party [NAME-ROLE] "GlobalChips-Seller", To party [NAME-ROLE] "GlobalChips-Buyer", Collaboration name "3A4"; also verify agreement effectiveToDate
Check: Make sure to verify Trading Partner Name, Trading Partner Parameters (Optional), Document Type Name, Document Type Revision ,Trading Partner Id, Delivery Channel
3. Document Validation Error
Check: 1. Make sure Document Revision Protocol Parameters i.e Transaction Envelope has valid values.
Proper ECS file is used for Validation. Make sure you have not used xsd instead of ecs file.
4. Connection Issues
Transport error: [IPT_HttpSendConnectionRefused] HTTP connection is refused. Connection refused: connect
Check : Make sure the information about delivery channel is correct and also the end point is active. This can be done by pinging the end points.
5. Duplicate Delivery channel
Check : Make sure you have not used the host ip address for configuring the Trading partner Delivery channel.
Posted by Ramesh Nittur at 7:19 AM 1 comments
Labels: B2B Document Editor, ERROR/Exception
Oracle AS B2B -EDI FAQ
1) Is it always mandatory to send the Edifecs XML to B2B for EDI processing?
It is possible to process Native EDI, Edifecs XML and any other flat file using Oracle AS B2B. Following are some of the features with native EDI/Flat File Processing.
· Translation should be switched off with optional validation.
· Oracle AS B2B would not provide features such as Batching, etc. with this configuration.
· It is required to send the complete envelope, as Oracle As B2B will not generate the envelope using Document Protocol Parameters like in case of Edifecs XML processing.
2) What if I have a native EDI file in the back end application can I process in B2B?
Refer to Q1.
3) What if I have a EDI document with multiple transactions, how do I handle in B2B?
Oracle AS B2B Processing is based on Transaction set, hence it is required to split the envelope into multiple transactions and send it to B2B. B2B translates the transaction set into native EDI and generates the envelope using the Document Protocol Parameters.
4) Can I receive EDI document with multiple transaction from a trading partner?
Yes. Oracle AS B2B provides a feature of debatching for inbound messages. Refer to section EDI Debatching for more details.
5) Can I outbound batch a native EDI documents to be sent to B2B from Back end application?
No, Refer Q1.
6) Can I identify the Trading partner using Interchange and group? How to enable this. What is the default method and most preferred method.
Default method and most preferred method is to identify the trading partner using Exchange. For identification based on Interchange/Group please add the following.
Refer to the section Trading Partner Identification for details.
7) Can I customize the group and Interchange ecs files? How?
Yes, it is possible to customize Group and Interchange ecs file using Oracle AS B2B Document editor. Refer to section User Experience while configuring EDI protocol in Oracle AS B2B for details.
8) Is there a need to redeploy the agreement in case of change in the ecs file. Does it require B2B restart?
Refer to section User Experience while configuring EDI protocol in Oracle AS B2B
9) Which database table holds the information about ecs and xsd files?
It is not advisable to access the tables directly as it is driven by the Business Logic layer of Oracle AS B2B.
select a.name from tip_parameter_t a, TIP_DOCUMENTTYPEPARAMETERVAL_T b where a.id = b.DOCUMENTTYPEPARAMETER and a.name like '%ECS%';
Need to link the following 2 tables to get to the DTD/XSD.
· tip_documentdefinition_t
· tip_nativedatatype_T
10) Can I migrate from Gentran system and what is the effort?
It is possible out of the box to migrate a Gentran map to Edifecs ecs file and back. Oracle AS B2B Document Editor provides out of the box features to do this migration. Refer to Document Editor Section for more details.
11) What is the preferred Exchange protocol for EDI?
EDI won’t mandate any Exchange protocol as such. However AS1/AS2 are the most popular exchange protocol which go well with EDI.
12) Can I disable the validation of incoming data against the document protocol parameter? Is it possible to identify the incoming document only based on ecs file?
Yes, it is possible to disable the validation of incoming document against Document protocol parameters.
Oracle.tip.adapter.b2b.edi.ignoreValidation=
Type: String
Default Value: None
Possible Values: EDI Interchange and Group envelope Parameters
Description: Users can specify a list of EDI Envelope Parameters to ignore their validation.
For e.g.: If users enters value InterchangeSenderID, InterchangeSenderQual for this property Oracle AS B2B will not validate Interchange Sender ID and Interchange Sender Qualification for the incoming message.
13) How to change the Recipient and sender Qualifier. Does it require a change in the ecs file?
This needs a change in the ecs file for any deviation from the EDI Standard .
For e.g to change the Interchange Qualifier to ‘zz’ which is not present in the list of default qualifier please do the following steps.
· Edit the Interchange ecs in the B2B Document Editor.
· Add the required qualifier i.e zz in S003-0007 and save the ecs file.
· Update the Interchange ecs file in the Document Protocol Parameter.
14) Can I implement Two-phase commit feature while batching?
Yes. By setting Oracle.tip.adapter.b2b.edi.OneErrorAllError=
Type= String
Default Value : False
Description : If the user wants the b2b server to stop processing all messages in a batch, set this flag to true., otherwise B2B server will process all valid messages and rejects only the messages that fail validation.
15) Is it mandatory to have Functional Acknowledgement in EDI.
No it is optional.
16) Consider the following batch criterion
Canon, 850, 4010, 1
Canon, 810, 4010, 1
Will B2B batch 850 and 810 documents into two separate wire messages?
By specifying No condition using 1 in the criterion column, B2B will create two batches one for 850 documents with revision 4010 and another for 810 documents.
Examples of specifying Criterion
- X12_ONE_TP will combine all X12 messages for one trading partner into one wire message
- X12_ALL_TP will combine all X12 messages for all the partners into one wire message
17) Is it required to turn on validation/translation to generate 997 in B2B.
Yes, it is a must to turn on either validation or translation to generate FA in B2B
18) How to delegate the Functional Acknowledgement generation to Back End Appliaction
Following are the two property of interest while defining the Operational Capability of the Trading partner .
a. Functional Acknowledgement Required : Set it to true to enable the Functional Acknowledgment
b. Is Acknowledgement Handled by Integration B2B : To determine whether B2B handles the Acknowledgement or Back end Application.
Posted by Ramesh Nittur at 7:03 AM 0 comments
Labels: EDI
Sunday, August 26, 2007
XMLGateway Integration
Most Prefferred way of integration of Oracle AS B2B to XMLGateway is throguh AQ i.e through a set of ECX_Inbound and ECX_outbound queues.
The following are the headers XMLG should set before it enqueues ino to ECX_OUTBOUND (like from, to, doc_type and doc_rev in case AQ),
MESSAGE_TYPE
MESSAGE_STANDARD
TRANSACTION_TYPE
TRANSACTION_SUBTYPE
DOCUMENT_NUMBER
PARTYID
PARTY_SITE_ID
PARTY_TYPE
PROTOCOL_TYPE
PROTOCOL_ADDRESS
USERNAME
PASSWORD
PAYLOAD
ATTRIBUTE1
ATTRIBUTE2
ATTRIBUTE3
ATTRIBUTE4
ATTRIBUTE5
among them TRANSACTION_TYPE ,TRANSACTION_SUBTYPE,PARTY_SITE_IDATTRIBUTE1 are mandatory. ECX* queue are not preseeded in B2B, instead they can be created by using the following script.
connect apps/apps
drop type ECXMSG;
/
create type ECXMSG as OBJECT (
MESSAGE_TYPE VARCHAR2(2000) ,
MESSAGE_STANDARD VARCHAR2(2000) ,
TRANSACTION_TYPE VARCHAR2(2000) ,
TRANSACTION_SUBTYPE VARCHAR2(2000) ,
DOCUMENT_NUMBER VARCHAR2(2000) ,
PARTYID VARCHAR2(2000) ,
PARTY_SITE_ID VARCHAR2(2000) ,
PARTY_TYPE VARCHAR2(2000) ,
PROTOCOL_TYPE VARCHAR2(2000) ,
PROTOCOL_ADDRESS VARCHAR2(2000) ,
USERNAME VARCHAR2(2000) ,
PASSWORD VARCHAR2(2000) ,
PAYLOAD CLOB ,
ATTRIBUTE1 VARCHAR2(2000) ,
ATTRIBUTE2 VARCHAR2(2000) ,
ATTRIBUTE3 VARCHAR2(2000) ,
ATTRIBUTE4 VARCHAR2(2000) ,
ATTRIBUTE5 VARCHAR2(2000)
);
/
begin
begin
dbms_aqadm.stop_queue('ECX_INBOUND');
exception when others then null; end;
begin
dbms_aqadm.stop_queue('ECX_OUTBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue('ECX_INBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue('ECX_OUTBOUND');
exception when others then null; end;
begin
dbms_aqadm.drop_queue_table('ECX_INQUEUE');
exception when others then null; end;
begin
dbms_aqadm.drop_queue_table('ECX_OUTQUEUE');
exception when others then null; end;
end;
/
declare
begin
dbms_aqadm.create_queue_table('ECX_INQUEUE','apps.ECXMSG',multiple_consumers=>FALSE);
dbms_aqadm.create_queue_table('ECX_OUTQUEUE','apps.ECXMSG',multiple_consumers=>FALSE);
dbms_aqadm.create_queue('ECX_INBOUND', 'ECX_INQUEUE');
dbms_aqadm.create_queue('ECX_OUTBOUND', 'ECX_OUTQUEUE');
dbms_aqadm.start_queue('ECX_INBOUND');
dbms_aqadm.start_queue('ECX_OUTBOUND');
end;
/
connect system/welcome1
grant execute on apps.ECXMSG to b2b
/
exit;
ENQUE SCRIPT :
The property values 'XML', 'OAG', 'POPI','POPI','1234','1234','1234' etc map to
MESSAGE_TYPE, MESSAGE_STANDARD, TRANSACTION_TYPE,
TRANSACTION_SUBTYPE, DOCUMENT_NUMBER ,
PARTYID,
PARTY_SITE_ID,
PARTY_TYPE,
PROTOCOL_TYPE
>>>>>>>>>>
create sequence poid_counter;
-- replace the TERMID 10193 with OM2N
CREATE OR REPLACE PROCEDURE enqueue_oag_message
IS
enqueue_options dbms_aq.enqueue_options_t;
message_properties dbms_aq.message_properties_t;
msgid RAW(16);
xmlgin SYSTEM.ECXMSG;
xmlgout SYSTEM.ECXMSG;
agent_in sys.aq$_agent;
agent_out sys.aq$_agent;
xml_payload varchar2(30000);
poid number(10);
BEGIN
select poid_counter.nextval into poid from dual;
xml_payload := ''||
'
'
'
'
'Langgt 23'||
'
'
'
'
'
'
'
'
'
'
'
'
'
'
'
;
/*message_properties.Correlation := 'WEBLOGIC';*/
message_properties.Correlation := 'ORACLE-AS-B2B';
/*msgid:='ORACLE-AS-B2B';*/
xmlgout := SYSTEM.ECXMSG('XML', 'OAG', 'POPI','POPI','1234','1234','1234',
'S', 'B2B', 'http://ap100jvm.us.oracle.com:8003/oa_servlets/oracle.apps.ecx.oxta.TransportAgentServer', 'saiqa', 'chowdry', xml_payload,
null, null, null, null, null);
dbms_aq.enqueue(queue_name => 'ECX_OUTBOUND',
enqueue_options => enqueue_options,
message_properties => message_properties,
payload => xmlgout,
msgid => msgid);
commit;
END;
/
Ensure to configure the ECX_OUTBOUND/ECX_INBOUND Internal delivery channel in B2B with appropriate IP address and SID.
Posted by Ramesh Nittur at 6:00 PM 0 comments
Labels: EBiz, XMLGateway
Trading Partner Identification in EDI Domain
Oracle AS B2B provides Identification of Trading partner at various levels.
1. Exchange level : This is the default identification based on the exchange Identifier. For e.g if the Exchange protocol used is AS2, then AS2 identifier i.e AS2-FROM is used for identification by comparing against the AS2 Identificer of the Trading partner.
2. Interchange/Group
This is a latest enhancement in B2B where in the identification happens in the order of sequence. Ideally it should be Exchange, Interchange and group. Currently B2B has facility to turn on TPIdentification based on Interchange or Group. This can be done by setting property in tip.properties
Example:
oracle.tip.adapter.b2b.edi.identifyFromTP=Interchange
OR
oracle.tip.adapter.b2b.edi.identifyFromTP=Group
If property is set to Interchange, B2B tries to identify TP using Interchange and if property is set to Group, B2B tries to identify TP using Group.
3. Trading partner Identification Any (newly Added)
If property is set to ANY, B2B will first try to identify TP using Interchange. If no TP found using Interchange, B2B will next try to find TP based on Group.
Example:
oracle.tip.adapter.b2b.edi.identifyFromTP=Any
Posted by Ramesh Nittur at 8:27 AM 3 comments
Labels: EDI, TP-Identification
Use of Document Routing ID in B2B
Oracle AS B2B comes with two different internal queues and are created based on IP_MESSAGE_TYPE structure whose definition is
as follows.
Name MSG_TYPE
MSG_ID Varchar(128)
INREPLYTO_MSG_ID Varchar(128)
FROM_PARTY Varchar(512)
TO_PARTY Varchar(512)
ACTION_NAME Varchar(512)
DOC_TYPE_NAME Varchar(512)
DOC_TYPE_REVISION Varchar(512)
MSG_TYPE Number(38)
PAYLOAD Clob
ATTACHMENT Blob
1. IP_IN_QUQUE
This is a default Internal Delivery Channel which is used for inbound communication i.e If the agreement do not have any
Internal Delivery Channel B2B uses this as the default internal delivery channel for sending the message to the back end
application. This comes pre-seeded with the product.
2. IP_OUT_QUEUE
This is a default Internal Delivery Channel which is used for outbound communication i.e for an internal application to send the message to the Trading Partner.This comes pre-seeded with the product.
Both of these are multi-consumer queues. Back end application uses consumer name attribute in the AQ message header to selectively deque the message from the IP_IN_QUEUE. For e.g If the BPEL Process has to deque only the HL7 message then the AQ adapter deque those messages whose consumer name is the same as what is configured in Document Routing ID for defining the HL7 Document type as part of B2B configuration.
Document Routing ID in Oracle AS B2B is part of the Document Type parameter in Document Definition Parameters page for a specific Document Type and is available as for all Document plugin in Oracle AS B2B. The default consumer name is b2buser when B2B Server enqueues to the IP_IN_QUEUE. This can be overrided by the Document Routing ID.
Following are the typical use cases supported by configuring the Document Routing ID.
1. TO distinguish between two Trading partner using the same Document Type.
2. To distinguish between two different Document Type belong to the same Trading partner.
You can change/Define/Override the Document routing ID for an existing Document Type for a specific Trading partner. This is done while defining the operational capability of a specific trading partner by unchecking the check box Use default Document definition and specifying appropriate Document Routing ID.
Posted by Ramesh Nittur at 8:25 AM 0 comments
Labels: Document Routing ID
Anonymous Trading Partner for HealthCare Protocol
Anonymous TP is a generic Concept in MLLP Exchange protocol, where in B2B will consider any Unrecognised Trading partner as "Anonymous" and honour the inbound HL7 message. Hence it is not possible to set any Trading partner specific configuration such as FA Required etc. as it is a generic Trading partner concept. Please set
oracle.tip.adapter.b2b.defaultTP=Anonymous
in tip.properties, and make sure to create a Trading Partner as Anonymous.
If B2B fails to Identify the Trading partner details from the incoming message it will consider the Trading partner as "Anonymous". Also, ensure to apply the patch # 6139949 for this feature.
Posted by Ramesh Nittur at 8:20 AM 0 comments
HL7 Best Practice Series
Following are some of the best Practice for HL7 Document Processing.
1. Validate the Edifecs xml document against the respective XSD in the back end application such as BPEL. This will ensure the validity of the document before sending it to BPEL.
2. Turn on the Validation for both inbound and Outbound HL7 Message for getting appropriate error message related to the validity of the document.
3. It is needed to either to enable validation/Translation for generating FA in B2B.
4. Make sure to use the same Document routing ID in B2B and BPEL for respective Document Definition.
5. Make sure to use the proper line delimiters in the document, also to define the same in the B2B configuration.
Many more to follow..
Posted by Ramesh Nittur at 8:16 AM 0 comments
Labels: Best Practice, HL7
Acknowledgement in Oracle AS B2B for HealthCare Protocol
Oracle AS B2B supports various types of Acknowledgement as part of HealthCare Protocol offering.
1. Functional Acknowledgement : The flag isFunctionalAck required controls whether an HL7 ACK) is needed are not. The flag isFunctionalAclHandledbyB2B controls when FA is required whether it is generated in B2B or it comes from Back End application such as BPEL. This option is useful only when isFunctionalAck required is YES. The flag isFunctionalAclHandledbyB2B should be set to 'YES', unless there is special way ACK is generated outside B2B. Functional Ack is generated using the XEngine in B2B and captures all the translation and validation errors.
2. Immediate Ack : The turn around time of Functional Acknowledgement is considered to be little high for some business critical healthcare application as it captures both translation, validation error and is generated by Xengine. An alternative in which case is Immediate Ack which is generated and transmitted in the TCP transport layer instead of the Document layer in case of FA resulting in response time as low as 1 sec.
Oracle AS B2B can send immediate acknowledgment in three modes and the same can be mentioned using the tip.property
oracle.tip.adapter.b2b.hl7.immediateAck= <mode>
default : B2B will parse the incoming HL7 message and generate ack from it.
In this mode b2b can send the ack to the sending application with correlation details (ex. Control number from the incoming Message, Sending App.. etc)
Hence TP Application can correlate the incoming ACK message.
simple : B2B will send the pre-defined ack message to the sender and will not parse the message.
custom : B2B will read the custom HL7 ack message based on a configurable file content.
oracle.tip.adapter.b2b.hl7.immediateAckFile =
Reads the file from the above location and send it as in ACK to the sender.
Posted by Ramesh Nittur at 7:46 AM 0 comments
Labels: Acknowledgement, HL7
SSL Setup for Oracle AS B2B
Please follow the below steps to configure B2B for SSL.
1. Configure SSL.
a. Edit Oracle_Home\opmn\conf\opmn.xml. Search for ssl-disabled and change it to ssl-enabled.
b. Startup Oracle Wallet Manager. Open the default wallet* in Oracle_Home\Apache\Apache\conf\ssl.wlt\default. Password is welcome.
c. Right click on “Trusted Certificates” Node and import the Remote Trading Partners Certificate.
d. Save the wallet in location Oracle_Home\Apache\Apache\conf\ssl.wlt\default and save as text file i.e b2bwallet.txt
e. Edit Oracle_Home\ip\config\tip.properties
f. Search for wallet location and change it to Oracle_Home\\Apache\\Apache\\conf\\ssl.wlt\\default\\b2bwallet.txt
g. In the Host Trading partner change the wallet password to "welcome"
h. Stop and start opmn – opmnctl stopall / opmnctl startall
* Note: Usage of default wallet is recommended only for Test. Request for a Server Certificate from a CA for actual usage.
2. Test SSL Configuration
a. Access Oracle Enterprise Manager.
b. Find the SSL port
c. Access the B2B Transport Servlet through the following the URL: https://hostname:sslport/b2b/transportServlet
3. Configure SSL for Trading Partners.
a.Log into the B2B UI Tool.
b. Click on Partners>>Trading Partners>>Select the Trading Partner>>Capabilities>>Select the Business Protocol>>Communication Capabilities>>Select Delivery Channel
c. Update Delivery Channel to enable Transport Security.
d. Update Transports details to select HTTPS 1.1 secure as the Transport Protocol.
e. Update Transport Server details to include the SSL port.
f. Repeat this for the remaining Trading Partner.
g. Create a Configuration and Deploy.
For a new wallet, please follow.
1. Create a new wallet with OWM (Oracle Wallet Manager).
2. Generate a certificate request from wallet manager for the host Acme.
3. Sign this certificate request from OCA (Oracle Certificate Authority).
4. Import the approved certificate in the wallet. The wallet now contains the ready certificate of host Acme.
5. Import the CA certificate. Wallet now contains the host certificate and CA root certificate. Also import the remote trading partners certificate. Wallet now has host,CA and remote trading partners certificate.
6. Export the wallet and save it as wallet.txt.
6. Update the tip.properties for wallet location to Oracle_Home\Apache\Apache\conf\ssl.wlt\default\wallet.txt. Also update opmn.xml for ssl-enabled.
7. Create the wallet password in host trading partner.
8. Create the delivery channel for host and remote trading partners with transport security enabled.
9. Create the agreement with working collaboration and secured delivery channels and deploy it.
10. Stop and start opmn – opmnctl stopall / opmnctl startall
Posted by Ramesh Nittur at 7:04 AM 0 comments
Labels: SSL
Oracle AS B2B Firewall Setup
Please find below the step by step instructions to setup and access B2B via DMZ.
This configuration is assumed to install B2B with in the firewall and standalone OHS in the DMZ and to obtain the firewall clearence for the Following port.
1. HTTP Port of OHS which sits in DMZ
2. HTTP Port of B2B which is with in the firewall.
Append the following lines to LoadModule section of standalone OHS
httpd.conf file
LoadModule proxy_module modules/mod_proxy.so (If it is already there then not required)
LoadModule proxy_http_module modules/mod_proxy_http.so
Add following lines to end of standalone Apache2.0 httpd.conf file
ProxyPass / http://
ProxyPassReverse / http://
To work above configuration, HTTP port on which B2B listens should be opened on internal firewall.
Testing of DMZ setup
----------------------
Restart standalone Apache 2.0
Invoke the following URL from any machine in DMZ using browser
http://
Above request initially goes to DMZ Apache and we have configured Apache to forward the request to B2B instance in intranet.It should display the
'transportServlet' parameters if everything goes well.
Above testing confirms that request is being passed from DMZ layer to Intranet layer but not from outside world to Intranet layer.
Testing from outside public network
-------------------------------------
Configure external firewall to accept the data for DMZ standalone Apache HTTP port.
Use the URL http://
It should display the 'B2B server' parameters if everything goes well.
DMZ setup with load balancer
-------------------------------
Optionally you can configure Load balancer like 'BigIP' on external firewall to route the requests to DMZ layer.
If you have DMZ layer front ended by load balancer then configure the load balancer to communicate with standalone HTTP server in DMZ.
In this case we expose the URL http://
Proxy configuration for B2B
-----------------------------
If you want to configure B2B to use proxy for all outgoing messages then read below.
Proxy server information needs to be provided in opmn.xml file of B2B midtier.
1) look for
2) then look for
4) look for
5) then look for
6) with in that tag make sure we should have
In the above tag we also have some additional security attributes keep them as they are.
Now restart B2B and oc4j_b2b components or all components.
Refer the following documents for various High availability questions.
http://download-east.oracle.com/docs/cd/B14099_19/tru64.1012/install.1012/install/topo.htm#BABCFDBI
http://download-west.oracle.com/docs/cd/B14099_19/core.1012/b14003/mt_comp.htm
Posted by Ramesh Nittur at 6:49 AM 2 comments
Labels: DMZ