Please follow new and interesting post in HL7Gurus What is HL7
Monday, January 26, 2009
Wednesday, January 21, 2009
Thursday, January 15, 2009
Verification & Vaildation of messages for ebMS in Oracle B2B
When a signed message comes into Oracle B2B using ebMS protocol, the following steps occur:
STEP 1: Verification:
The ebMS protocol itself does the verification by extracting the certificate from the message and uses this certificate to verify the signed message.
STEP 2: Validation
An additional feature of Oracle B2B is to perform another step after STEP1 for validation. Here, the public key in the repository is compared with that of the message. The public in the repository is uploaded while configuring the trading partner.
This feature can be turned off by adding the following property in the tip.properties:
*oracle.tip.adapter.b2b.tpa.verifyCertificate=false*
Further, it is strongly recommended that this additonal feature be turned off (by adding the above property) while working with high performance environments.
Posted by Suhas P Hiremagalur at 9:51 AM 0 comments
Labels: EBMS, validation, verification
Exception handling in Rosettanet
While processing an inbound RosettaNet message, there are chances of the message being erronous due to vaious reasons.
The likely cause could be in
1.Rosettanet Exchange specific values mismatch in either service header or delivery header
2.Error Document validation
In this case, B2B will send an exception message back to the trading partner. This is an automatic process of creating the exception message and sending back to trading partner and this does not need any additional configuration.
It is different from PIP 0A1 processing. In the case of PIP 0A1, an Exception message is trigger by B2B Engine for any error/exception, where as NOF has to be sent by the Back end application.
Posted by Dheeraj Kumar M at 5:20 AM 0 comments
Labels: PIP 0A1, RosettaNet
Friday, January 9, 2009
Security Configuration in Oracle AS Integration B2B
Practice Lesson
Security Configuration in Oracle AS Integration B2B
Security Configuration In Integration B2B
Introduction:
There are three ways of providing security in Oracle AS Integration B2B.
1. Encryption
2. Digital Signature (Sign).
3. SSL
Security Setup:
Step1 : Create a self signed certificate for the host using the Oracle Certificate Authority, the tutorial for the same is as below.
http://www.oracle.com/technology/products/oid/oidhtml/sec_idm_training/html_masters/devapp06.htm
Alternatively it is possible to obtain a certificate from the CA(certificate Authority like Verisign or Thwarte) . Certificate extension should not matter, as long as you use x.509 compliant certificate.
Step2: Import the host certificate into the Oracle Wallet along with the Root certificate.
Step 3: Make sure you have specify the wallet location properly (folder name) in the file
E.g. oracle.tip.adapter.b2b.WalletLocation = c:/tmp/soa/b2b
Step 4: Using Oracle Integration B2b, The following are the steps to configure for secured way of transferring messages between trading partners.
-> Select Partners
-> Select Trading Partner
->Select Acme
-> Click on “Update”
Enter the following information
General Page: Enter the wallet Password information
New Wallet Password
Confirm New Password
->Click Apply
step 5: Setting up the Host Delivery Channel:
For providing the Security Information for Host Trading Partner (Acme)
Create Communication Capability
-> Select Trading Partners
-> Select Acme
-> Select Capabilities
-> Select
-> Select Create Communication Capability
Delivery Channel Page
Prompts to define the following delivery channel details for the secure exchange of messages between trading partners:
· Delivery channel name
· Acknowledgment mode
· Global usage code
· If nonrepudiation of receipt and nonrepudiation of origin are Required
· If encryption, transport security, and compression are enabled
· Time to acknowledgment value
· Retry count value
Note: The selections you make on this page for nonrepudiation of receipt, nonrepudiation of origin, encryption, and transport security determine the fields that display and the transport protocols that are selectable on subsequent pages of this wizard.
Document Exchange Page
Prompts to define the following document exchange characteristics for exchanging messages between trading partners
· Document exchange name
· Exchange protocol revision and parameter values.
· Document exchange protocol parameters
· Digital signature, signing credential, and certificate file if you Selected “Yes” for nonrepudiation of receipt and nonrepudiation of origin on the Delivery Channel page.
· Digital envelope, encryption credential, and certificate file if you selected “Yes” to enable encryption on the Delivery Channel
page.
In the Document Exchange window, enter the following information,
Encryption:
There is a need to select Digital Envelope algorithm depending on whether encryption is enabled.
New encryption credential can be created using create new or use the existing Encryption credentials. For new credentials use Browse button to locate Host certificate as it is used to decrypt the message. Make sure this certificate should be available in the e-wallet.
Non-Repudiation: If Non-Repudiation is enabled then select the Digital Signature and Signing credentials. Use Browse button to locate Host certificate for Digitally Signing the outbound Message. Make sure this certificate should be available in the e-wallet.
B2B engine uses the certificate from the repository for both signing and encryption and also a lookup to the wallet for Private key, hence there is a need to import the host certificate into the wallet as well.
Note: There is another way to specify the Certificates,
-> Select Partners
-> Select Trading Partner
-> Select Acme
-> Click on “Create” under Certificate
Enter the following information
Name: <Any valid Name>
Certificate File: <Using browse to locate the certificate >
->Click Apply
Use this certificate while creating the Delivery Channel by selecting “Use Existing”.
Step 6: Setting up the Trading Partner Delivery Channel:
Providing the Security Information for Remote Trading Partner (GlobalChips)
Create Communication Capabilities
->Select Trading Partners
->Select GlobalChips
->Select Capabilities
->Select <Business protocol>
->Select Create Communication Capability
Delivery Channel Page
Prompts to define the following delivery channel details for the secure exchange of messages between trading partners:
· Delivery channel name
· Acknowledgment mode
· Global usage code
· If nonrepudiation of receipt and nonrepudiation of origin are Required
· If encryption, transport security, and compression are enabled
· Time to acknowledgment value
· Retry count value
Note: The selections you make on this page for nonrepudiation of receipt, nonrepudiation of origin, encryption, and transport security determine the fields that display and the transport protocols that are selectable on subsequent pages of this wizard.
Document Exchange Page
Prompts to define the following document exchange characteristics for exchanging messages between trading partners
· Document exchange name
· Exchange protocol revision and parameter values
· Document exchange protocol parameters
· Digital signature, signing credential, and certificate file if you Selected “Yes” for nonrepudiation of receipt and nonrepudiation of origin on the Delivery Channel page
· Digital envelope, encryption credential, and certificate file if You selected “Yes” to enable encryption on the Delivery Channel
Page
In the Document Exchange window, enter the following information,
Encryption:
There is a need to select Digital Envelope algorithm depending on whether encryption is enabled.
New encryption credential can be created using create new or use the existing Encryption credentials. For new credentials use Browse button to locate Trading Partner certificate as it is used to encrypt the outbound message.
Non-Repudiation: If Non-Repudiation is enabled then select the Digital Signature and Signing credentials. Use Browse button to locate Trading Partner certificate for Digital signature verification for the inbound message.
SSL - Security
Configure SSL:
1. Edit Oracle_Home\opmn\conf\opmn.xml. Search for ssl-disabled and change it to ssl-enabled.
2. Startup Oracle Wallet Manager. Open the default wallet* in Oracle_Home\Apache\Apache\conf\ssl.wlt\default. Password is welcome.
3. Right click on “Trusted Certificates” Node and import the Remote Trading Partners Certificate.
4. Save the wallet in location Oracle_Home\ip as b2bwallet.txt
5. Edit Oracle_Home\ip\config\tip.properties
6. Search for wallet location and change it to Oracle_Home\\ip\\b2bwallet.txt.
7. 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.
Test SSL Configuration:
1. Access Oracle Enterprise Manager.
2. Find the SSL port
3. Access the B2B Transport Servlet through the following the URL: https://hostname:sslport/b2b/transportServlet
Configure SSL for Trading Partners.
1. Log into the B2B UI Tool.
2. Click on Partners>>Trading Partners>>Select the Trading Partner>>Capabilities>>Select the Business Protocol>>Communication Capabilities>>Select Delivery Channel
3. Update Delivery Channel to enable Transport Security.
4. Update Transports details to select HTTPS 1.1 secure as the Transport Protocol.
5. Update Transport Server details to include the SSL port.
Repeat the same for all remaining Trading Partners.
Create a Configuration and Deploy.
Posted by Nandhu at 1:28 AM 0 comments
Labels: Security
Thursday, January 8, 2009
monitoring and cleaning internal queue
Sometime it is required to remove persistence data within B2B. This script will be very useful for cleaning any event stuck in internal B2B queues.
1) this script to find count of messages in queue.
SELECT a.queue_table, a.name, b.waiting, b.ready, b.expired FROM
dba_queues a, v$aq b WHERE a.qid = b.qid AND owner = 'B2B';
2)cleaning messages from specific queue table. in case, you are using inbound AQ, queue table is 'IP_QTAB'.
declare po dbms_aqadm.aq$_purge_options_t;
begin
po.block := FALSE;
dbms_aqadm.purge_queue_table(
queue_table => 'EVENT_QTAB',
purge_condition => NULL,
purge_options => po);
end;
Posted by Vaibhav at 1:26 PM 0 comments
Labels: oracle b2b persistence
Thursday, January 1, 2009
Monitoring All the AQ in B2B
In order to monitor all the AQ (Advanced Queues) related to B2B the following query can be used.
SELECT a.queue_table, a.name, b.waiting, b.ready, b.expired FROM dba_queues a, v$aq b WHERE a.qid = b.qid AND owner = 'B2B';
Posted by Prasanna at 10:27 PM 0 comments