SOA Basic- Real components of SOA Suite

                                                  Basic-Real Components of  Oracle SOA

                        Oracle SOA Suite components as below,

                        ■ Oracle Enterprise Service Bus

                        ■ Oracle BPEL Process Manager

                        ■ Human Task

                        ■ Oracle Business Activity Monitoring

                        ■ Oracle Complex Event Processing

                        ■ Oracle User Messaging Service

                        ■ Separately Licensed Products

BPEL Test case creation

Steps for creation of Test Suite and Test Cases

a) Open up the BPEL process project in Oracle Jdeveloper.
b) Expand the Integration Content section in the Application Navigator.
c) Right click on the “Test Suites” subsection and click on “Create a new Test Suite” in the context menu.
d) Give a name to the Test Suite, preferably with the same name as your process suffixed with “TestSuite”.
For instance, CreateCustomer process shall have a test suite named CreateCustomerTestSuite.
e) Once the Test Suite has been created, expand the “Test Suites” subsection and right click on the test suite
name to create a new Test Case, by clicking “Create BPEL Test”.
f) Give a name to the Test case, preferably as the Process Name suffixed by “TestCase<index>”, where
<index> is “1” for the first testcase, “2” for the second, and so on. Leave the checkbox “Add as Baseline
Test” unchecked. Press OK to complete the selection.
g) The Test Case graphical view opens up. The next step would be to emulate the receive activity with a static
input file.
h) To obtain a static input file, use any available input files you may have already saved onto the local file
system, or obtain a fresh one from the audit trail of an existing execution of the BPEL process instance.
i) Double click on the receive activity.
j) Switch to the “Emulate” tab and check the radio button “Emulate Message”.
k) Click on the flashlight to select the input XML file from the local file system.
l) Press “OK” to complete the selection.



Now, the test case is ready for deployment.

a) Right click on the “Test Suites” subsection in the “Applications Navigator” and select “BPEL Test deployer’.
b) Select the test suite and the test case(s) to be deployed, and then make your selection of the deployment
environment.
c) Click on “Deploy” to deploy the test suite.


Executing the Test Case from the BPEL Console

a) Navigate to the BPEL Console and click on the Process.
b) Click on the “Test Suites” tab to view the available test suite and test cases.
c) Check the test suite/test case that you wish to execute and click on the “Execute Tests” button to execute
the test.

Timeout Error - Process Instances not appearing in BPEL console

Problem Occurance  

Oracle(R) BPEL Process Manager - Version: 10.1.2 to 10.1.3
This problem can occur on any platform.

Reason 

 

New BPEL process instances are not visible in the BPELConsole.
However, Instance activity can be seen in the domain.log.
Additionally you may see transaction timeout errors in the Domain.log

Root-Cause

At the application server J2EE layer, the JTA transaction timeout is less than the time it takes to perform an activity.

The recommended JTA transaction timeout value should be increased to the total time of the sync activity or exec activity, then add 2-3 minutes.

Solution

To implement the solution, please execute the following steps:

1. Within the J2EE application container level, increase the JTA transaction timeout value to the
expected total time of a sync activity or exec activity, then add 2-3 minutes.
2. Restart the container and retest.

If using OAS, this is configured via the iasconsole > midtier:instance > OC4J:instance > config > server.xml > transaction-config timeout parameter that by default is set to 30000. 

Info on this parameter:
Oracle® Application Server Containers for J2EE, User’s Guide, 10g Release 2 (10.1.2)
Part No. B14011-01
Page 116/144
http://download-west.oracle.com/docs/cd/B14099_09/web.1012/b14011.pdf

<transaction-config>
Transaction configuration for the server.
Attribute:
■ timeout="30000" — Specifies the maximum amount of time (in milliseconds) that a transaction can take to finish before it is rolled back due to a timeout. The default value is 30000. This timeout will be a default timeout for all transactions
that are started in OC4J. You can change it by using the dynamic API—UserTransaction.setTransactionTimeout(milliseconds).
In OAS / OC4J / SOA Suite 10.1.3 this parameter is no longer supported.  Instead this is defined through the Application Server Control url, and then: oc4j_soa instance > administration > under SERVICES / Transaction Manager (JTA) > administration > under GENERAL, modify 'Transaction Timeout'. Apply and restart the container.  For more details see: Oracle® Containers for J2EE Services Guide, 10g (10.1.3.1.0), Part Number B28958-01 -  http://download-west.oracle.com/docs/cd/B31017_01/web.1013/b28958/jta.htm
Additionally, Appendix A1.1 of the BPEL Developer Guide goes into detail for each of the timeout settings, at http://download-west.oracle.com/docs/cd/B31017_01/integrate.1013/b28981/app_trblshoot.htm#sthref3957

NOTES: The 'syncMaxWaitTime' parameter in the Manage / BPEL Domain link of the BPELConsole can also be modified to alter the maximum time the process result receiver will wait for a result before returning. Results from asynchronous BPEL processes are retrieved synchronously via a receiver that will wait for a result from the container.  This can useful when debugging transaction timeout errors that can sometimes accompany the main subject of this Note.

OSB FAQS -1

Third Party Compatibilty and Certifications....

1.Can Oracle ESB Run in a Third-Party J2EE Container (JBoss, WebSphere, WebLogic)?

Oracle ESB is certified to run on WebSphere (as is Oracle BPEL Process Manager).
Certification on WebLogic and JBoss is currently in progress.

2.Can I Use a Third-Party JMS Provider (TIBCO, WebSphereMQ, SonicMQ) as the Internal
Oracle ESB Transport?

In 10.1.3.1, Oracle ESB requires OEMS for its internal usage. However, Oracle ESB has
been designed to be provider-agnostic and Oracle may certify other vendors' JMS
providers based on demand (for customers who already have a JMS provider in-house
and do not want to learn and manage an extra JMS provider).
Oracle already supports many other vendors' JMS providers on the edges (that is,
Oracle ESB can listen to and send messages on many different JMS providers).

3.Can Oracle ESB Send to or Receive from a Third-party JMS Provider (TIBCO EMS,
WebSphere JMS)?

Yes. Oracle ESB, or more precisely the JMS adapter, supports a large number of
third-party JMS providers. The following file shows how to send and receive against
TIBCO EMS:
j2ee/SOA_CONTAINER/application-deployments/default/JMSAdapter/oc4j-ra.xml

4.What Databases are Supported as a Storage Backend for the ESB Server?

At this point, only Oracle databases are supported as a storage backend for the ESB
Server. Oracle Lite is installed as part of the basic developer installation on Windows.
Use Oracle Database 10g for production hosts.

5.On Which Operating Systems Does Oracle ESB Run?

Oracle ESB is part of Oracle Application Server, and runs on the same operating
systems as that. See the certification matrix for the most up-to-date information:
http://www.oracle.com/technology/software/products/ias/files/oracle_
soa_certification_101310.html

6.How Can I Use an Oracle 10.1.2 Database Server on a Windows Client Workstation with
Oracle ESB and Oracle SOA Suite?

Normally, the Oracle Database server can only be installed on a Windows Server, such
as 2000 or 2003 Server.
For development purposes, Oracle SOA Suite bundles Oracle Lite as part of the basic
installation to minimize the installation footprint of using a full Oracle database. You
can also use the advanced installation option and configure it to run against Oracle XE,
which works fine on Windows XP.

7.Can I Consume Oracle ESB Services from .NET Clients?

It is completely possible. Be sure to install and develop the .NET clients with
VisualStudio SDK 3.0 and use VisualStudio 2005 Service Pack 1. There are problems if
the .NET clients are not developed with these components.

8.Which Adapters are Available with Oracle ESB?

All adapters supported by Oracle BPEL Process Manager are available in Oracle ESB:
■ Technology adapters (file, FTP, MQSeries, database, AQ, and JMS)
■ OracleAS Adapter for Oracle Applications
■ Third-party adapters:
– Applications (J.D. Edwards OneWorld, SAP, PeopleSoft, and Siebel)
– Legacy (CICS, IMS/DB, IMS/TM, Tuxedo, and VSAM)

9.How Do I Connect to a Protocol or Application for which Oracle Does Not Have an
Adapter?

You can always write Java code and integrate either using WSIF Java binding or by
building a custom JCA adapter.
Oracle provides technology, application, and mainframe adapters. Others may be
available through our partners in a co-sell model (that is, sold on partner paper and
supported by the partner). Current Oracle SOA Suite adapter partners are iWay,
Pervasive (specialize in small-to-medium size business applications), Attunity
(specialize in mainframe adapters), GT Software (specialize in adapters for mainframe
platforms z/OS, MVS, and VSE), NetManage, and Ericom (specialize in screen scraper
adapters). If you still do not find an adapter for your application, you likely need to
understand the architecture for the target system and application and look at using our
available technology adapters.

10.Can You Create an ESB-to-ESB Bridge Across a Firewall?

Oracle ESB can connect through a firewall on the edges using traditional MOM
technologies such as the FTP adapter and SOAP/HTTP Web services with proxy. The
10.1.3 OC4J JMS Router component can also send JMS messages across a firewall over
HTTP(S). Oracle ESB does not internally support any node-to-node communications
through a firewall for asynchronous routing rules or any internal Oracle ESB JMS
topics.

11.How Do I Call an Oracle ESB Routing Service from ADF?

You create a Web service proxy, as shown in section 10.3 of the Oracle SOA Suite
Tutorial. This question came up on the SOA Oracle Technology Network forum:
http://forums.oracle.com/forums/thread.jspa?threadID=451847

12.Can Oracle ESB Handle Inbound HTTP Posts?

Yes, by writing a J2EE servlet that receives the HTTP POST or GET and invokes an
Oracle ESB service. The HTTP WSIF provider can generate outbound HTTP requests.
Additionally, Oracle is considering building an HTTP adapter if customer demand is
sufficient. Send customer requests to vikas.anand@oracle.com.

14.Does Oracle ESB Support WSIF and are Samples and Additional Information Available?
Yes, Oracle ESB supports WSIF. There are samples available on the Oracle ESB Oracle
Technology Network page (http://www.oracle.com/technology/goto/esb).
There is an article on WSIF entitled "Using WSIF for Integration" that is recommended
for anyone looking to understand and make use of the benefits of WSIF. Additionally,
Oracle ESB relies more heavily on WSIF for Java integration because Oracle ESB does
not include the EXEC Java functionality that is included in Oracle BPEL Process
Manager.

15.Does Oracle ESB Support RPC Style SOAP Services?

No, Oracle ESB 10.1.3 does not support RPC style SOAP services, binary attachments,
or multipart WSDLs.

SOA Conceptual Architecture...

In recent years, many enterprises have evolved from exploring pilot projects using ad-hoc adoption of SOA and expanded to a defined repeatable approach for optimized enterprise-wide SOA deployments. All layers of an IT SOA architecture have become service-enabled and comprise of presentation services, business processes, business services, data services, and shared services.


Typical SOA Conceptual architecture exists as below,

Throttling in OSB

In Oracle Service Bus, you can restrict the message flow to a business service. This technique of restricting a message flow to a business service is known as throttling. 

Limiting the concurrent requests for a Business Service cannot be set at design time so you have to use the built-in Oracle Service Bus Administration Console to do it (/sbconsole). Follow these steps to enable it:

1. In Change Center, click Create to start a new Session
2. Select Project Explorer, and navigate to the Business Service you want to limit
3. Select the Operational Settings tab of the View a Business Service page
4. In this tab, under Throttling, select the Enable check box. By enabling throttling you
   1. Specify a value for Maximum Concurrency
   2. Specify a positive integer value for Throttling Queue to backlog messages that has exceeded the message concurrency limit
   3. Specify the maximum time in milliseconds for Message Expiration a message can spend in Throttling Queue
5. Click Update
6. Click Active in Change Center to active the new settings

If you re-publish the service, it will not overwrite the settings. Only if the resource is renamed or moved, it will.

Please note that a throttling queue is an in-memory queue. Messages that are placed in this queue are not recoverable when a server fails or when you restart a server.

Oracle BPEL Dehydration Table details....

cube_instance - stores instance metadata, eg. instance creation date, current
state, title, process identifier

cube_scope - stores the scope data for an instance ... all the variables
declared in the bpel flow are stored here, as well as some internal objects to
help route logic throughout the flow.

work_item - stores activities created by an instance ... all BPEL activities in
a flow will have a work_item created for it. This work item row contains meta
data for the activity ... current state, label, expiration date (used by wait
activities) ... when the engine needs to be restarted and instances recovered,
pending flows are resumed by inspecting their unfinished work items.

document - stores large XML variables. If a variable gets to be larger than a
specific size (configurable via the largeDocumentThreshold property via the
domain configuration page) then the variable is stored in this table to
alleviate loading/saving time from the cube_scope table.

audit_trail - stores the audit trail for instances. The audit trail viewed
from the console is modelled from an XML document. As the instance is worked
on, each activity writes out events to the audit trail as XML which is compress
ed and stored in a raw column. Querying the audit trail via the API/console wil
l join the raw columns together and uncompress the contents into a single XML do
cument.

audit_details - audit details can be logged via the api ... by default
activities such as assign log the variables as audit details (this behavior can
be set via the auditLevel property on the domain configuration page). Details a
re separated from the audit trail because they tend to be very large in size ...
if the user wishes to view a detail they click a link from the audit trail page
and load the detail separately. There is a threshold value for details too ...
if the size of a detail is larger than a specific value (see auditDetailThreshol
d) then it is place in this table, otherwise it is merged into the audit trail r
ow.

dlv_message - callback messages are stored here. All non-invocation messages
are saved here upon receipt. The delivery layer will then attempt to correlate
the message with the receiving instance. This table only stores the metadata
for a message. (eg. current state, process identifier, receive date).

dlv_message_bin - stores the payload of a callback message. The metadata of a
callback message is kept in the dlv_message table, this table only stores the
payload as a blob. This separation allows the metadata to change frequently
without being impacted by the size of the payload (which is stored here and
never modified).

dlv_subscription - stores delivery subscriptions for an instance. Whenever an i
nstance expects a message from a partner (eg. receive, onMessage) a subscription
is written out for that specific receive activity. Once a delivery message is r
eceived the delivery layer attempts to correlate the message with the intended s
ubscription.

invoke_message - stores invocation messages, messages which will result in the
creation of a instance. This table only stores the metadata for an invocation
message (eg. current state, process identifier, receive date).

invoke_message_bin - stores the payload of an invocation message. Serves the
same purpose the dlv_message_bin table does for dlv_message.

task - stores tasks created for an instance. The TaskManager process keeps its
current state in this table. Upon calling invoking the TaskManager process, a
task object is created, with a title, assignee, status, expiration date, etc...
When updates are made to the TaskManager instance via the console the
underlying task object in the db is changed.

schema_md - (just added via patch delivered to Veerle) contains metadata about
columns defined in the orabpel schema. Use case driving this feature was how
to change the size of a custom_key column for a cube_instance row? Changing
the db schema was simple but the engine code assumed a certain length and
truncated values to match that length to avoid a db error being thrown. Now, co
lumn lengths are defined in this table instead of being specified in the code.
To change a column length, change the column definition in the table, then chang
e the value specified in this table, then restart the server.


Column-by-column description:

table ci_id_range

- next_range (integer) - instance ids in the system are allocated on a block
basis ... once all the ids from a block have been allocated, another block is
fetched, next_range specifies the start of the next block.


table cube_instance

- cikey (integer) - primary key ... foreign key for other tables
- domain_ref (smallint) - domain identifier is encoded as a integer to save
space, can be resolved by joining with domain.domain_ref.
- process_id (varchar) - process id
- revision_tag (varchar) - revision tag
- creation_date (date)
- creator (varchar) - user who created instance ... currently not used
- modify_date (date) - date instance was last modified
- modifier (varchar) - user who last modified instance ... currently not used
- state (integer) - current state of instance, see com.oracle.bpel.client.
IInstanceConstants for values
- priority (integer) - current instance priority (user specified, has no impact
on engine)
- title (varchar) - current instance title (user specified, no engine impact)
- status (varchar) - current status (user specified)
- stage (varchar) - current stage (user specified)
- conversation_id (varchar) - extra identifier associated with instance, eg. if
passed in via WS-Addressing or user specified custom key.
- root_id (varchar) - the conversation id of the instance at the top of the
invocation tree. Suppose A -> B -> C, root( B ) = A, root( C ) = A, parent( B )
= A, parent( C ) = B. This instance, instance at the top of the tree will not
have this set.
- parent_id (varchar) - the conversation id of the parent instance that created
this instance, instance at the top of the tree will not have this set.
- scope_revision (integer) - internal checksum of scope bytes ... used to keep
caches in sync
- scope_csize (integer) - compressed size of instance scope in bytes
- scope_usize (integer) - uncompressed size of instance scope in bytes
- process_guid (varchar) - unique identifier for the process this instance be
longs to ... if changes need to be made for all instances of a process, this col
umn is used to query (eg. stale process).
- process_type (integer) - internal
- metadata (varchar) - user specified


table cube_scope

- cikey (integer) - foreign key
- domain_ref (integer) - domain identifier
- modify_date (date) - date scope last modified
- scope_bin (blob) - scope bytes


table work_item

- cikey (integer) - foreign key
- node_id (varchar) - part of work item composite key, identifier for bpel
activity that this work item created for
- scope_id (varchar) - part of work item composite key, identifier for internal
scope that this work item created for (note this is not the scope declared in
bpel, the engine has an internal scope tree that it creates for each instance,
bpel scopes will map to an internal scope but there will be other internal
scopes that have no mapping to the bpel definition).
- count_id (integer) - part of work item composite key, used to distinguish
between work items created from same activity in the same scope.
- domain_ref (integer) - domain identifier
- creation_date (date)
- creator (varchar) - user who created work item ... currently not used
- modify_date (date) - date work item was last modified
- modifier (varchar) - user who last modified work item ... currently not used
- state (integer) - current state of work item, see com.oracle.bpel.client.
IActivityConstants for values
- transition (integer) - internal use, used by engine for routing logic
- exception (integer) - no longer used
- exp_date (date) - expiration date for this work item; wait, onAlarm
activities are implemented as expiration timers.
- exp_flag (integer) - set if a work item has been called back by the
expiration agent (ie. expired).
- priority (integer) - priority of work item, user specified, no engine impact
- label (varchar) - current label (user specified, no engine impact)
- custom_id (varchar) - custom identifier (user specified, no engine impact)
- comments (varchar) - comment field (user specified, no engine impact)
- reference_id (varchar) -
- idempotent_flag (integer) - internal use
- process_guid (varchar) - unique identifier for the process this work item
belongs to ... if changes need to be made for all instances of a process, this
column is used to query (eg. stale process).


table document

- dockey (varchar) - primary key for document
- cikey (integer) - foreign key
- domain_ref (integer) - domain identifier
- classname (varchar) - no longer used
- bin_csize (integer) - compressed size of document in bytes
- bin_usize (integer) - uncompressed size of document in bytes
- bin (blob) - document bytes
- modify_date (date) - date document was last modified


table audit_trail

- cikey (integer) - foreign key
- domain_ref - domain identifier
- count_id (integer) - many audit trail entries may be made for each instance,
this column is incremented for each entry per instance.
- block (integer) - when the instance is dehydrated, the batched audit trail
entries up to that point are written out ... this block ties together all rows
written out at one time.
- block_csize (integer) - compressed size of block in bytes
- block_usize (integer) - uncompressed size of block in bytes
- log (raw) - block bytes


table audit_details

- cikey (integer) - foreign key
- domain_ref (integer) - domain identifier
- detail_id (integer) - part of composite key, means of identifying particular
detail from the audit trail
- bin_csize (integer) - compressed size of detail in bytes
- bin_usize (integer) - uncompressed size of detail in bytes
- bin (blob) - detail bytes


table dlv_message

- conv_id (varchar) - conversation id (correlation id) for the message...this
value is used to correlate the message to the subscription.
- conv_type (integer) - internal use
- message_guid (varchar) - unique identifier for the message...each message
received by the engine is tagged with a message guid.
- domain_ref (integer) - domain identifier
- process_id (varchar) - identifier for process to deliver the message to
- revision_tag (varchar) - identifier for process revision
- operation_name (varchar) - operation name for callback port.
- receive_date (date) - date message was received by engine
- state (integer) - current state of message ... see com.oracle.bpel.client.
IDeliveryConstants for values
- res_process_guid (varchar) - after the matching subscription is found, the
process guid for the subscription is written out here. - res_subscriber
(varchar) - identifier for matching subscription once found.


table dlv_message_bin

- message_guid (varchar) - unique identifier for message
- domain_ref (integer) - domain identifier
- bin_csize (integer) - compressed size of delivery message payload in bytes
- bin_usize (integer) - uncompressed size of delivery message payload in bytes
- bin (blob) - delivery message payload


table dlv_subscription

- conv_id (varchar) - conversation id for subscription, used to help correlate
received delivery messages.
- conv_type (integer) - internal use
- cikey (integer) - foreign key
- domain_ref (integer) - domain identifier
- process_id (varchar) - process identifier for instance
- revision_tag (varchar) - revision tag for process
- process_guid (varchar) - guid for process this subscription belongs to
- operation_name (varchar) - operation name for subscription (receive,
onMessage operation name).
- subscriber_id (varchar) - the work item composite key that this subscription
is positioned at (ie. the key for the receive, onMessage work item).
- service_name (varchar) - internal use
- subscription_date (date) - date subscription was created
- state (integer) - current state of subscription ... see com.oracle.bpel.
client.IDeliveryConstants for values
- properties (varchar) - additional property settings for subscription


table invoke_message

- conv_id (varchar) - conversation id for message, passed into system so
callbacks can correlate properly.
- message_guid (varchar) - unique identifier for message, generated when
invocation message is received by engine.
- domain_ref (integer) - domain identifier
- process_id (varchar) - identifier for process to deliver the message to
- revision_tag (varchar) - revision tag for process
- operation_name (varchar) - operation name for receive activity
- receive_date (date) - date invocation message was received by engine
- state - current state of invocation message, see com.oracle.bpel.client.
IDeliveryConstants for values
- priority (integer) - priority for invocation message, this value will be used
by the engine dispatching layer to rank messages according to importance ...
lower values mean higher priority ... messages with higher priority are dispatch
ed to threads faster than messages with lower values.
- properties (varchar) - additional property settings for message


table invoke_message_bin

- message_guid (varchar) - unique identifier for message
- domain_ref (integer) - domain identifier
- bin_csize (integer) - compressed size of invocation message payload in bytes
- bin_usize (integer) - uncompressed size of invocation message payload in bytes
- bin (blob) - invocation message bytes


table task

- domain_ref (integer) - domain identifier
- conversation_id (varchar) - conversation id for task instance ... allows task
instance to callback to client
- title (varchar) - current title for task, user specified
- creation_date (date) - date task was created
- creator (varchar) - user who created task
- modify_date (date) - date task was last modified
- modifier (varchar) - user who last modified task
- assignee (varchar) - current assignee of task, user specified, no engine
impact
- status (varchar) - current status, user specified, no engine impact
- expired (integer) - flag is set if task has expired
- exp_date (date) - expiration date for task, expiration actually takes place
on work item in TaskManaged instance, upon expiration task row is updated
- priority (integer) - current task priority, user specified, no engine impact
- template (varchar) - not used
- custom_key (varchar) - user specified custom key
- conclusion (varchar) - user specified conclusion, no engine impact

About Me...

To Introduce...

Am Anitha R ,out of self interest creating this BLOG to share my technical experience that would be of lil help to anyone in tech industry..

Current experience in SOA 3 years and 2.8 years of exp in Java/J2EE/Struts development..

Here We go ..with small tries/tips & tricks...:)