We have installed various versions of Oracle BRM on multiple platforms countless times. The installation process is mostly free of pain now, still it is a time consuming task. Imagine you have to replicate it across a dozen development, test and integration instances and eventually into production. Suddenly managing configuration files and port numbers manually becomes a mission impossible.
For development and training purpose, the answer is simple, it's VM. Virtualization is a technology spread-headed by VMWare, it is now also adopted by Oracle. A VMWare Oracle BRM image is a virtual machine running CentOS, containing a Oracle database and a functioning BRM environment. Just drop it into a VMWare player and voilà, you are set. The BRM image on Oracle VM follows the same principle, but it is a little more cumbersome to use. Oracle VM Server installs itself on a physical server, thus if you want it to be portable, be prepare to have a i7 Quadcore laptop. We start with a template let's say OEL5 and 11g database, install the out-of-the-box BRM once, then save and reuse the template. Nowadays we can produce VMWare or Oracle VM BRM images on any supported configuration.
Okay what about deploying BRM into production environments with various configuration? To do that we'll introduce a Release Management concept built specifically for this purpose. Please stay tune.
Tuesday, April 6, 2010
Wednesday, February 3, 2010
Integration Using Oracle Stream Advanced Queues
Oracle Advanced Queues have been around for a while. It was part of Oracle DBMS since 8.1.5. Now as part of Oracle Streams it provides database-integrated message queuing functionality. You get persistent or non-persistent queuing model, local or remote propagation and all operational benefits of high availability, scalability, and reliability of the underlying database.
It has always been a challenge to integrate BRM with other enterprise applications. The inbound interface is available in C/C++/Java/Perl, but the learning curve to be familiar with data structure and programming concept is steep. On the outbound direction, the native Data Manager framework also requires intensive coding and detailed knowledge of BRM, data format and interface API you want to talk to.
For a recent integration project we've decided to employ Oracle AQ for both inbound/outbound real-time and batch transactions between BRM and EBS. Each application maintains the inbound and the outbound AQ in its local database. The outbound BRM AQ is linked to the inbound EBS AQ; similarly the outbound EBS AQ is linked to the inbound BRM AQ using AQ propagation mechanism.
Each application is responsible for enqueuing and dequeuing operation of its own queues. The Oracle Streams AQ platform is responsible for message delivery, propagation, transactional integrity, persistence and high availability.
Since 7.3.1 BRM provides a DM_AQ component, which allows dumping business events with XML payload into an Oracle AQ. We leverage this existing data manager to push payload for real-time transactions such as inventory item changes and orders from BRM to the external system.
On the inbound we develop a new custom data manager which uses OCI to dequeue messages from the inbound queue. Thus BRM is able to pull payload for real-time transactions from the external system.
The database-to-database AQ propagation is used to move messages between the queues. The propagation setup is the trickiest part, but in the end the whole scheme has been a success.
It has always been a challenge to integrate BRM with other enterprise applications. The inbound interface is available in C/C++/Java/Perl, but the learning curve to be familiar with data structure and programming concept is steep. On the outbound direction, the native Data Manager framework also requires intensive coding and detailed knowledge of BRM, data format and interface API you want to talk to.
For a recent integration project we've decided to employ Oracle AQ for both inbound/outbound real-time and batch transactions between BRM and EBS. Each application maintains the inbound and the outbound AQ in its local database. The outbound BRM AQ is linked to the inbound EBS AQ; similarly the outbound EBS AQ is linked to the inbound BRM AQ using AQ propagation mechanism.
Each application is responsible for enqueuing and dequeuing operation of its own queues. The Oracle Streams AQ platform is responsible for message delivery, propagation, transactional integrity, persistence and high availability.
Since 7.3.1 BRM provides a DM_AQ component, which allows dumping business events with XML payload into an Oracle AQ. We leverage this existing data manager to push payload for real-time transactions such as inventory item changes and orders from BRM to the external system.
On the inbound we develop a new custom data manager which uses OCI to dequeue messages from the inbound queue. Thus BRM is able to pull payload for real-time transactions from the external system.
The database-to-database AQ propagation is used to move messages between the queues. The propagation setup is the trickiest part, but in the end the whole scheme has been a success.
Subscribe to:
Posts (Atom)