eProseed has accomplished it's first go-live with 12c technology

We are pleased to announce that eProseed has accomplished its first go-live with 12c technology working with CFL - The Luxembourgish National Railway Company.

With this implementation, CFL accomplished a high-reliable, agile and flexible integration platform across various heterogeneous application - existent in and off-premises - empowering CFL monitoring and control capabilities in addition to a faster customer on-boarding.

eProseed team’s expertise enhanced the new SOA Suite 12c capabilities enabling to deliver a short time-to-market solution based in standards and best practices that lays a solid foundation for future coming projects.

This first phase is cornerstone of a broader IT transformational project where CFL wants to put in place a full SOA platform capable of handling all the communications between its internal applications and their partners.

The synergies between the SOA 12c components, namely B2B and OSB products, are key for building a solid and flexible integration layer to implement a variety of interfaces that enable CFL to communicate easily and efficiently with all of their partners.

Installation of Oracle B2B 12c

In this post I will quickly go through the steps that are necessary in order to install Oracle B2B and create a SOA domain that you can use.

I will consider that the installation will be used for a development environment and that it is done on the Linux machine.

Note that prior to the installation of B2B you will need to have machine running a Database and perform the installation of Oracle Fusion Middleware 12c Infrastructure and of the Oracle Fusion Middleware 12c SOA Suite and Business Process Management on the same machine where you will be installing B2B. You will also need to have the latest Oracle JDK 7 Update installed on that same machine.

The necessary software can be downloaded using Oracle eDelivery:

• V44959-01.zip – Latest Oracle JDK 7 Update for Linux x86-64 (Prerequisite)
• V44416-01.zip – Oracle Fusion Middleware 12c (12.1.3.0.0) Infrastructure (Prerequisite)
• V44420-01.zip – Oracle Fusion Middleware 12c (12.1.3.0.0) SOA Suite and Business Process Management (Prerequisite)
• V44421-01.zip – Oracle Fusion Middleware 12c (12.1.3.0.0) B2B and Healthcare

To install Oracle Fusion Middleware 12c Infrastructure please refer to:
Oracle Fusion Middleware Installing and Configuring the Oracle Fusion Middleware Infrastructure

To install Oracle Fusion Middleware 12c SOA Suite and Business Process Management please refer to:
Oracle Fusion Middleware Installing and Configuring Oracle SOA Suite and Business Process Management

I'm considering that a new domain will be configured from scratch. If a SOA domain was already created previously a few of the next steps can be ignored and the existing domain can be extend to include B2B. If that is the case, for the next steps, remember to shutdown any running instances of Weblogic Server.

     1. The first part of the installation will be to install the software:

After you have downloaded the V44421-01.zip file unzip it:

[oracle@linuxMachine stage]$ unzip V44421-01.zip

and you will obtain a file: fmw_12.1.3.0.0_b2bhealthcare.jar. Run this file:

[oracle@linuxMachine stage]$ java -jar fmw_12.1.3.0.0_b2bhealthcare.jar

and you will be presented with the Oracle Universal Installer. Follow the onscreen instructions:

     2. The second part of the installation is to run the Repository Creation Utility (RCU) to create the necessary schemas.

Note: If you have executed the RCU previously to create a SOA domain you can skip this step.

Navigate to ORACLE_HOME/oracle_common/bin 

and execute RCU:

[oracle@linuxMachine bin]$ ./rcu

Follow the onscreen instructions. 

A special note for the Custom Variables - Step 5 of 8 screen:

Since I'm installing a development environment I will chose a SMALL database profile. I also chose not to install the Healthcare on the software installation so I chose NO on the Custom Variables screen.

   3. The third part of the installation is to create and configure your domain.

Navigate to ORACLE_HOME/oracle_common/common/bin 
and execute the domain configuration application:

[oracle@linuxMachine bin]$ ./config.sh

Follow the onscreen instructions. 

Note: if you already have a SOA domain created you can follow the similar steps by selecting to Update an existing domain and adding Oracle B2B - 12.1.3.0 [soa] on the second screen of the configuration wizard.

Note: If you are extending the domain and you have custom data sources that were created before the extension, a new screen will show up before this screen. Check the Datasources row and click Next. The test data source screen will verify its validity. Click Next.

After these 3 steps your SOA Domain will now be configured and enabled for B2B. Start your Admin and SOA servers and navigate to: http://<server_ip>:<soa_server_port>/b2bconsole and you're all set to start using B2B!

Additional information can be found at: Oracle Fusion Middleware Installing and Configuring Oracle B2B and Healthcare

Oracle B2B 12c - HTTP Generic Channel with transport callout

First of all, season's greetings to everyone! 

Then, let me introduce this post saying that, already in the version 11g, a generic HTTP listening channel for message posting to B2B using the HTTP protocol was available. Any configured trading partner could use this generic channel to post messages to B2B.

A single common URL was available by default:
http://[host-name]:[host-port]/b2b/httpReceiver 

In this way, a single listening channel is able to serve multiple trading partners for every HTTP communications with B2B. 

When this channel is used, the process follows the default steps for message processing, namely:

• Sender identification (i.e. using HTTP Header);
• Document protocol/version/type identification ;
• Agreement identification;
• Message processing (parsing and validation);
• Synchronous delivery to a back-end application.

The only differentiation factor is: since this channel is generic and not configurable or even available on the list of listening channels in B2B console, make it unavailable for channel callout configuration. 

This has now changed with the 12c version.

With the version 12c of B2B is now possible to define a generic HTTP transport callout and associate it with a specific transport level callout.

As of now, this is driven by an B2B configuration Fusion Middleware property that needs to be added on Oracle Enterprise Manager Fusion Middleware Control (EM) 

b2b.HTTPTransportCalloutName= [callout name] 

i.e. b2b.HTTPTransportCalloutName= InboundGeneralCallout

Note: Access the following Oracle documentation for full instruction on how to set EM B2B properties here. 

This is also isolated from the regular HTTP functionality since a new ulr is provided to be able to establish this new feature. 

There is now a separated URL to be used in case of setting a generic HTTP channel callout: 

http://[host-name]:[host-port]/b2b/calloutReceiver

With this, the callout will be triggered when the message is received in this URL and EM property is configured for a valid transport callout.

Wish you all a very prosperous 2015!

Oracle B2B 12c - Listening Channel activation and deactivation in bulk

With the version 12c of B2B the possibility to activate and deactivate all listening channels in one single command was introduced. Previously, it was necessary to provide the name of the listening channels to perform the action, what, in scenarios with a considerable number of listening channels, made the task ineffective.

Different scenarios can be pointed out where this functionality is extremely useful:

• After importing a B2B configuration the channels are always in deactivated status. This command can be then executed in order to activate all the listening channels in bulk;
• Deactivate all listening channels to stop momentously all message consumption for corrective or preventive reasons into B2B or back-end applications;
• Switching the message consumption between two environments;

The feature is also provided in a command line based approach since is an extension to the already existing feature of enable/disable a particular listening channel. Therefore it is respecting the same prerequisites.

Prior to executing any B2B command line tool is necessary to set the following environment variables:

JAVA_HOME: Your Java home

ORACLE_HOME: Your oracle SOA home

ANT_HOME: Your ant home

For example:

export JAVA_HOME=/usr/java/jdk1.7.0_51

export ORACLE_HOME=/u01/fmw/soa/

export ANT_HOME=/u01/fmw/oracle_common/modules/org.apache.ant_1.9.2

export PATH=$PATH:$ANT_HOME/bin

After, the first command to execute is the one which create a jndi.properties file in the folder where the SOA ant build artefact are available. The jndi.properties file allows defining the connection details to execute any of the available B2B command tools.

cd $ORACLE_HOME\bin

ant -f ant-b2b-util.xml b2bcreate-prop

A jndi.properties files is created in the folder. Now is time to edit it in order to reflect the connection details.

java.naming.provider.url=t3://localhost:8001
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory
java.naming.security.principal=weblogic
java.naming.security.credentials=weblogic_password

All ready to run authenticated commands as the listening channel activation and deactivation command.

From the same directory where ant-b2b-util.xml exists execute:

ant -f ant-b2b-util.xml updatechannel -Dchannelname="*" -Dstate=active

ant -f ant-b2b-util.xml updatechannel -Dchannelname="*" -Dstate=inactive

By providing the channelname as “*” all the listening channels can be activated / deactivated.

Note: The operation is performed incrementally going throughout the listening channels and activating one by one. With a large number of listening channels it can take some time between the activation and the moment that all the channels start to consume messages. Be patient and check your logs and monitor B2B in order to check the message consumption is starting.

Oracle B2B 12c - Document Callouts: The Concept

One of the coolest new features of that Oracle B2B 12c brings is the document callout.

Callouts had already an important role on previous releases of Oracle B2B and they allow for execution of custom Java code on different steps of a message process.

On previous versions we had already 2 types of callouts:

• Transport or channel callouts: this type of callouts add the possibility to execute custom java code on the wire message, as soon as it is received on the channel on the inbound or before being sent for final delivery on the outbound
• Agreement callouts: this type of callouts add the possibility to execute custom java code on the application message (the XML representation of the message) , just before being sent to the backend on the inbound or immediately after being received from the backend on the outbound.

With the new document callout B2B brings the possibility of executing custom java code to convert your raw format message into XML or vice-versa replacing the default xEngine as your parsing tool.

This is particularly useful for those complex messages that can not be defined using the document editor.

Note: For those of you still using Oracle B2B 11g this feature (and many others) is available by installation of patch SOA bundle Patch 19190139 11.1.1.7.5 

On a future post I will show you how to use this cool new feature!

Stay tunned!

Oracle B2B 12c – What’s New!

This post serves as the first of a series of posts dedicated to Oracle B2B.

What better way to start this series than to highlight the many new features have been added to Oracle B2B 12c which can change the landscape of the target usage for B2B.

Let's look at some of these new features:

• Document Translation Callout Framework
• Introduced Document Callout for custom document parsing (inbound), validation and construction (outbound)
• Regular Expression Document Identification
• Trading Partner Metadata API
• Parameters, Identifiers and TP Agreements accessible via Java API and WS
• SSL Support for SMTP
• Trading Partner Identifier via Regular Expression
• Batching of Custom Documents
• xPath payload extraction from SOAP Body
• xEngine (B2B Native Parser) API for EDIFACT
• Bulk Listening Channel activation
• Enriched exchange information on message metadata
• Channel used
• Agreement 
• Priority on Document Identification
• Message IN/OUT Collaboration by ID
• Improved Provisioning Self Service 
• Callouts
• Identifiers
• Parameters
• Channel details
• Incremental Update

Note: All of this features are available for the version 11g of SOA Suite by installation of patch SOA bundle Patch 19190139 11.1.1.7.5 

In 12.1.3 there's:

• Support for streaming (effective process for large payloads)
• MFT as an integration channel
• Enhanced End2End monitoring and integration with Error Hospital
• Local Policy Attachment for Web Services

In future posts we will go into more details on these and other B2B features.

Stay tunned!

Resolving localhost on clustered environment

After a clustered SOA Suite installation we were setting the deployment script to point to localhost when referencing another composites. Although, we were unable to resolve localhost connection in run time trowing the following exception every time that a composite tried to reference another composite:

oracle.fabric.common.FabricInvocationException
Tried all: '2' addresses, but could not connect over HTTP to server: 'localhost', port: '8101'

Turns out that the reason was related with the fact that the port 8101 was not listening on the localhost address. This was reveled executing the following command:

:~$ netstat -na | grep 8101

10.1.5.67.8101       172.28.251.83.53878  65840      0 129100      0 TIME_WAIT
10.1.5.67.8101       172.28.251.83.53880  65840      0 129100      0 TIME_WAIT

The list reveled that only one ip was related with port 8101 so by this we could conclude that localhost was not listening to this port.

Therefore, in order to solve it, we needed to change the IP address range that the servers are listening for incoming connections.
Going to weblogic console and checking the server configuration we could observe that the listen address was set with the machine IP, so in this way limiting the incoming connection to the ones referencing only this IP:

The solution was to remove the IP from the Listen Address field leaving this undefined so clients can reach this server using localhost string.

Saving the changes, applying the modifications and restarting the server made available the composites on the servers to be invoked by clients using localhost in the reference.