SOA Suite 10g Developer Guide

   http://www.scribd.com/doc/209017569/SOA-Suite-10g-Developer-Guide"  style="text-decoration: underline;" >SOA Suite 10g Developer Guide

by http://www.scribd.com/tusjain"  style="text-decoration: underline;" >tusjain

Oracle Fusion Middleware Naming Conventions

OS Level Naming Standards

 

Local Application-Related Account Standards

The local account naming syntax incorporates information about the account, application, and type of environment.

 

<       

 

 

: 3 characters

E.g.:  soa - SOA / integration application:

E.g.:   obi -  a BI / reporting application

E.g.:   oid -  an OID (Oracle LDAP)  application

 

< account type>: 5 characters

  

    User: user

    Group: group

   

E.g.:  soauser is the user account for SOA environment

            Oiduser is the user account for Oracle Identity Environment.       

Note: All user accounts should be local and should have sudo privilege to execute command as root.

 

Goup Name Standards

The primary group name of a local account named following the previous suggested naming standards, it should be:

E.g.:  soagroup – primary group name of user account soauser

 

Note: All group names should be local.

Application Level Naming Standards

 

Assumptions

Each server will come with a dedicated storage which is represented by a mounted volume name.

This volume is mounted under /apps/oracle.

 

Oracle Home Naming Standard

/apps/oracle/product/fmw/

:   <=  7 characters

Standard component names:

owsm

aia 

soa

E.g.:  /apps/oracle/product/fmw/soa

         /apps/oracle/product/fmw/aia

 

During Installation of Oracle Software , specify /apps/oracle as the oraInventory directory.

 

Application Instance Naming Standard

These names are usually setup during the application installation process. The names are visible in Enterprise Manager / Administration Tools type of software like Oracle Grid Control for instance and appended with the FQDN of host.

 

: 7 characters

 

Provides description of the application components installed.

 

E.g.: soa, owsm, intgtwy, extgtwy

 

 

: 1 character (number)

 

E.g.: soa1, owsm1

                   (First instance of the component in an Oracle Application Cluster)

 

 

J2EE Instance Naming Standard

Following the best practices when we deploy new applications in OC4J containers we need to create new OC4Js.

OC4J_

: <= 5 characters

Example:  oc4j_soa, oc4j_esbdt

 

 

BPEL Domains Naming Standard

The BPEL domain name should have a prefix that has the business process name and NOT the Project Name given for a particular business process.

_

: <= 5 characters

Example:  mdm_product, mdm_customer

 

Note: The BPEL domain should only have “Lower case letters” and should NOT contain Upper case or mixed case for domain names. As this will cause errors, when you try to restrict the domain access based on the project/ user access for particular domains.

 

 

ESB System Naming Standard

 

The ESB System name should adequately reflect the Business Process name or the Application component type. There are no additional restrictions on the service group that are under the ESB System.

 

System

 

: <= 5 characters

Example:  AIASystem, BPELSystem

Book Review: Oracle BAM 11gR1 Handbook

Book Review: Oracle BAM 11gR1 Handbook by Pete Wang: Publisher- Packt: ISBN- 13: 978-1849685443

Oracle BAM 11gR1 Handbook talks about the subject in very concise and efficient manner. Pete has assumed that reader of this book will be having basic knowledge of Oracle Fusion Middleware 11g and SOA Suite in particular which is fair.

First chapter touches the architectural aspects but literally it touches. If book has given the deep dive that might have added more value to it. Book should have covered data model of BAM in detail.

Book focuses on hands on and how which is good for beginners but experienced are also interested in why as well. Book is helpful in understanding of features of Oracle BAM 11g.

Chapters on testing and High Availability cover the topics which will help many readers.

Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author. I got electronic format of book from publisher for review.

Further reading: Oracle BPM Suite 11g Developer's cookbook (http://www.amazon.com/Oracle-BPM-Suite-Developers-cookbook) is complementary book.

 One can get more information about book and related topics from:
 1. Amazon: http://www.amazon.com/Oracle-11gR1-Handbook-Pete-Wang/dp/1849685444
 2. Publisher – Packtpub: http://www.packtpub.com/oracle-business-activity-monitoring-11gr1-handbook/book
 3. Virtual m/c and appliance download for Oracle Fusion 11g: http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html
 4. Oracle Fusion Middleware Documentation Library: http://docs.oracle.com/cd/E12839_01/index.htm

Patch Application Life Cycle

One of my friend, Abhishek recently defined the Patch application life cycle for Fusion SOA Suite.

Steps

1.    Get patch from Oracle.
2.    Study Readme for applying patch.
3.    Try to apply Patch.
4.    Patch application fails.
5.    Confirm back to Oracle.
6.    a. Oracle provides an un-official Patch. Goto Step 8
                 OR
        b. Oracle Unable to provide a solution.
7.    Devise a workaround on your own to apply patch.
8.    Apply Patch successfully.
9.    Ask all the application teams to test their application.
10.  Patch does not solve the issue it was applied for.
11.  Rollback Patch.
12.  Ask all the application teams to test their application.

Book Review: Oracle Fusion Middleware Patterns

Book Review: Oracle Fusion Middleware Patterns by Harish Gaur and, Markus Zirn: Publisher- Packt: ISBN- 13: 978-1847198327

Oracle Fusion Middleware pattern book is a collection of case studies for Oracle Fusion Middleware across the globe and across the industry. This book is primarily targeted to planners and high level business decision makers with hints of technical stuff. With respect to target audience, packtpb site indicates for IT manager but, I differ here.

Book can be read online at http://www.oracle.com/technetwork/articles/entarch/index-098853.html.

Book is divided into three groups: Process Improvement, Business Visibility, and Collaboration and Security to club case studies accordingly.

Book is good read for staff members of enterprises who are moving to Oracle Fusion Middleware stack.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.


One can get more information about book and related topics from:

1. Book’s web presence http://www.oracle.com/technetwork/articles/entarch/index-098853.html
2. Amazon: http://www.amazon.com/Oracle-Fusion-Middleware-Patterns-Harish/dp/1847198325
3. Publisher -- Packtpb https://www.packtpub.com/enterprise-solution-architecture-patterns-by-oracle-fusion-middleware/book
4. Harish Gaur’s Blog: http://blogs.oracle.com/harishgaur/2010/10/fusion_middleware_patterns.html
5. Surachart Opun’s Review: http://surachartopun.com/2010/09/oracle-fusion-middleware-patterns-book.html
6. Wow Books Review: http://www.wowebook.com/business/oracle-fusion-middleware-patterns.html

Performance Tuning in OFMW SOA Suite

A. SOA Component Level
a. BPEL/BPMN Engine Level
i. Concurrency
1. # of Threads to process invocation messages (dspInvokeThreads)
2. # of Threads to process engine messages (dspEngineThreads)
3. # of Threads to process system messages dspSystem Threads
ii. Memory/DB
1. Audit Trail logging levels (AuditLevel)
2. Message Persistence (oneWayDeliveryPolicy)
iii. CPU
1. XML Validations (validateXML)
2. Statistics for most recently processed requests (statsLastN)
b. BPEL/BPMN Process Level
i. Response Time:
1. Parallel processing of invole in multiple branches (nonBlockingInvoke)
2. Synchronous / Transient process design
ii. Database
1. Dehydration needed or not (inMemoryOptimization)
2. Instance data storage in DB (completionPersistPolicy)
iii. CPU
1. Payload Validation (validateXML)
c. Mediator
i. Concurrency
1. Parallel Routing ( # of parallel threads for message processing )
2. Resequencer ( # of worker threads )
ii. Database
1. Audit Level
2. Parallel Routing (# of rows that are fetched by each thread per iteration )
3. Resequencer (# of Groups that are locked by each thread at a time )
iii. CPU
1. Metrics Level
2. Sleep intervals before next polling
d. Database Adapters
i. Concurrency
1. # of worker / Poller / Dequeue threads
ii. Database
1. # of rows to be processed per transaction (MaxTransactionSize)
2. # of file records to be processed (MaxRaiseSize)
3. Collect stats on relevant tables
4. Large files
iii. CPU
1. Process design
2. IO
3. # Threads at the application server level
B. SOA Infrastructure Level
a. Database
i. Audit Level
ii. Purging
b. CPU
i. Payload Validation
C. Generic
a. Operating System
b. JVM
i. Heap Size
ii. Nursery Size
iii. GC Algorithm
iv. Use Large pages
v. 64 bit vs 32 bit
c. Database
i. SOA & Application Schema tuning
ii. Tuning Parameters
iii. Redo Logs
d. WebLogic Application Server
i. Production Mode
ii. Connection Pooling
iii. Logging
iv. Self tuning

Oracle BPEL PM: Developer

Oracle SOA - Developer

Oracle BPEL PM: Administration

Oracle SOA - Ad Mini Start Ion

Book Review: BPEL Cookbook: Best Practices for SOA-based integration and composite applications development

Book Review: BPEL Cookbook: Best Practices for SOA-based integration and composite applications development Edited by Harish Gaur and Markus Zirn: Publisher- Packt: ISBN- 1-904811-33-7

BPEL Cookbook is not about BPEL but for Oracle BPEL Process Manager. This book contains ten case studies which ranges from real implemented business scenarios to examples listed at Oracle web site.

The book starts with very simple case study but with each new chapter complex and difficult scenario unfolds.

The book is structured into three logical parts. Part one is talking about integration using Oracle BPEL Process manager. This part covers first three case studies. Part two covers usage of Oracle BPEL Process Manager in little more complex applications including product development. This part is covered in case study number four, five and six. The last part covers SOA techniques which spans from chapter seven to ten.

My favorite case studies from book are “Building Rich Internet Applications for Workflow and Process Monitoring”, “Building BPEL Process on the fly”, Making BPEL Process Dynamic”, and “Using WSIF for Integration”.

The book is good reminder of BPEL Process Manager capabilities. The best way to read this book is to start realizing the scenarios.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Effective Java by Joshua Bloch http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683

One can get more information about book and related topics from:

1. Book’s web presence http://www.oracle.com/technology/pub/articles/bpel_cookbook/index.html
2. Amazon: http://www.amazon.com/BPEL-Cookbook-integration-applications-orchestration/dp/1904811337
3. Publisher – Packt- http://www.packtpub.com/BPEL-SOA/book
4. Flipkart: http://www.flipkart.com/bpel-cookbook-stany-blanvalet-jeremy/8184042388-aw23foexoc

Managing Deployment Parameters in BPEL Process Manager

In BPEL PM 10.1.3.4, concept of deployment plan is introduced. I found its documention quite fuzzy and without support of examples. I have developed the same for my team and clients. I hope you will also find the same useful.

Download the word file from scribd.com. This doc also contain one process which is zipped and embedded into it.

Oracle Fusion BPEL Process Manger’s Process as Product: Architecture & Design

Recently, I architected and designed few Oracle BPEL PM processes as product for a SAAS application and systems integrating with it. The processes were developed as products so SAAS provider can sell them repeatedly to its customers.

These processes were architected & designed under following business and technical constraints and conditions:

1. Use of Oracle Fusion Middleware is mandatory.
2. Minimize the software license cost for SAAS provider and its customers.
3. Minimize development cost for SAAS provider.
4. Minimize customization cost for SAAS provider’s customers.
5. Minimize product support cost for SAAS provider and its customers.
6. Customers must be able to customize the processes.
7. With the deployment of upgraded version of process (not the BPEL Fusion Middleware upgrade), customization of customers must be preserved. Manual intervention must be minimum.
8. Processes must be designed keeping Oracle Fusion Middleware road map in sync.

So the decision on selection of Oracle Fusion Middleware was already done.

Bust still lot of architectural and design decision were to be taken.

A. The first decision was to not to use AIA framework. This decision was based on following considerations:

a. Additional license cost of AIA
b. Skills need for AIA were not available in-house and even with independent service providers. Development of skill set or getting from outside was costly in-terms of time and money.
c. AIA is pretty new kid on the block.
d. There is no clear-cut road map for AIA.

B. For processes there were two choices: BPEL PM and ESB. BPEL PM was chosen over ESB for development of processes because of:

a. Processes were quite complex and involved lot of service orchestration. So BPEL was in and ESB was out.
b. Any BPEL PM process can be registered with ESB so even if processes were developed in BPEL PM, they can be registered with ESB if required in future without any changes required in process code.
c. To reduce license cost for SAAS provider and its customers.

C. To manage Errors and Exceptions, error hospital of Oracle Fusion Middleware and especially BPEL PM. Errors & Exceptions were classified as:
a. Business
b. Application & Logic
i. Binding
ii. a
c. System
d. Miscellaneous

Retry mechanism of BPEL PM was employed to care of transient faults in IT assets like network, database, connecting systems, etc. Error & Exception Management was developed as separate collection of processes, which primarily catered to:

a. Handling of Errors & Exceptions
b. Logging of Errors & Exceptions
c. Notification of Errors & Exceptions

Individual business processes handled error & exception but Logging & Notification was completely outsourced to maximize the reuse of services across business processes.

To achieve replay of service remediation framework was developed. The options available to log and remediate errors and exceptions were:

a. JMS queue
b. Direct database store
c. Advance Queue

JMS queue was not able to win favor due to requirement of separate JMS server in enterprise, which was directly increasing investment and operational costs.

Direct database store was also not able to win positive note due to higher development & maintenance cost.

AQ was on high due to native support from Oracle Database and only one time operational cost – during first deployment: AQ enablement on database.

Compensatory services were also developed because of usage of Asynchronous processes and need to maintain transaction integrity.

D. From experience in similar products using TIBCO and SAP XI following learnings were noted:

a. Customers customize processes
b. Customers don’t like to override their customizations with introduction of newer version of processes by SAAS provider.
c. Lot of human intervention needed to preserve customization done by customers. This is error prone way.
d. Most of mapping is done in m aping where elements from source and target applications were mapped.
e. Interface definitions of source and target applications seldom changes during their lifetime. In simple language Schema of source and target message changes only when one of application changes which is rare.

To resolve these challenges two approached were evaluated:

a. Three processes based approach

To ease in handling customization by SAAS provider’s customers, each business process will be divided into three BPEL processes. For example a business process where Data flows from SAAS to Oracle eBusiness Suite, one BPEL Process will cover data fetch from and data submission to Oracle eBusiness Suite while other two will do the transformation & Mapping.






Here the idea is that in Process-2, data is mapped from SAAS Schema to eBusiness schema in the default way (SAAS Provider way). This process will deployed as separate process in BPEL Process Engine server.

The Process-3 also maps the data but it has some twist. In its mapper this process should have two input schemas (SAAS and eBusiness) and one output schema (eBusiness). The default mapping will be of one to one mapping (eBusiness to eBusiness) but client may modify as per their need.

Process -2 and Process-3 will be deployed separately and will communicate via XML. Process-2 will pass XML to process-3.

Now SAAS Provider releases second version of its product then it gives only process-1 & 2 as upgrade not the process-3. In this case client can choose not to update process-3 to preserve its customization. This approach assumes that only mapping changes from version to version not the schema.

This approach may have performance issue due to communication overhead.


b. Multiple Mapping files based approach





In this approach customer will be provided two sets of mapping. Customer will not modify Mapping-1 but Mapping-2 will be. With the new release of process, customer will retain XSL referring to Mapping-2, which will preserve his customization.


In both approaches only Mapping customizations are taken care not the changes in Schemas and upgrade in BPEL Process Manager.

The choice of approach will be decided with some performance test on the sample process.


E. Products were involving big EIS (Enterprise Information System) s and SAAS application which were serving complex business processes. Often to increase reliability and support business process are deployed different instances of EIS on the basis of geographies or business lines. So there were two possible cases:

a. n:1 scenario
b. 1:n scenario

a. n:1 scenario

In the scenario where data will be fetched from multiple Oracle eBusiness Suite and fed into single SAAS instance, multiple instances of a BPEL Process will be deployed with updated connection details for Oracle eBusiness Suite.



b. 1:n scenario

Content based routing will be achieved via switch case. To achieve 1:n (input:output systems) switch based approach is simpler and clean.



The other approach to achieve content based routing is ESB. But in ESB the targets are again defined at Design Time only. There is no way one can define target systems at deployment or run time. To reduce the number of systems involved, BPEL solution with switch case is preferred.

But option was left open to customer so if customer wishes, BPEL process can be registered at ESB and ESB based routing can be availed.

TIBCO SOA Tool set

I thought of comparing TIBCO SOA toolset with that of Oracle Fusion, so architects and business people both can compare them. So I have made the following diagram.