Introduction to Oracle BPEL (Business Process Execution Language)

Abstract
This article gives an overview to develop Service-Oriented Architecture (SOA) application using oracle BPEL.

Introduction
The World Wide Web Consortium (W3C) defines service-oriented architecture (SOA) as: “a set of components which can be invoked, and whose interface descriptions can be published and discovered.”

* An architectural style for loose coupling between interacting software agents or services using standard web service(SOAP) protocol.
* A set of component that can be invoked

SOA Components



Introduction to Web Services

Web services enable loosely coupled, reusable software components that semantically encapsulate discrete functionality and are distributed and programmatically accessible over standard Internet protocols.

* Simple Object Access Protocol (SOAP) is used to invoke the Web service.
* Web Services Description Language (WSDL) is used to describe the Web service.
* Universal Description, Discovery and Integration (UDDI) is used to publish and query Web services.

The following are file formats used extensively by Web service standards:
XML: Extensible Markup Language (XML) is a set of rules for defining data markup in a plain text format.
XSD: XML Schema Definition (XSD) specifies how to formally describe the elements in an XML document.
XSL: Extensible Stylesheet Language (XSL) is a specification (or template) for separating style from content when creating HTML or XML pages.
XSLT: Extensible Stylesheet Language Transformations (XSLT) is the language used in XSL style sheets to transform XML documents into other XML documents.
XPath: XML Path (XPath) is a language with a set of syntax rules for defining parts of an XML document.

What Is BPEL?

- A markup language for composing multiple services into an end-to-end business process
- A workflow and process flow language
- Synchronous and asynchronous interactions
- Parallel processing
- Exception management
- Provides a way to integrate a set of heterogeneous services to implement business processes

Integrated Adapters


Oracle BPEL Process Designer provides a wizard-driven model approach to exposing various systems and services as a Web service through WSDL generated to publish operations that can be performed by the service.

JDeveloper BPEL Designer provides an adapter framework that supports the following types of adapters:
- File Adapter
- FTP Adapter
- Oracle Advanced Queuing (AQ) Adapter
- Database Adapter
- JMS Adapter
- Oracle Applications Adapter

Difference between Oracle ESB and BPEL

Oracle BPEL is a Business Process Execution Language and as such its optimised for managing and coding business processes, whereas an ESB is quite simply a highly efficient intergration product. Its principle objective is to join two different services together quickly, efficiently and bi-directional. ESB does not have the Sensors which can be used to monitor the activities that can send actions to Business Activity Monitoring (BAM) or database/jms.BPEL data transformations enrich and perform complex changes whereas ESB can perform only simple transformations.

Primarily BPEL is used for Orchestration, data enrichment and also for Human interaction whereas ESB is used for Store and forward transport of data.

Specifically an ESB moves data via
Connects services via different adaptors (WebServices, FTP,File,JDBC etc) and protocols (HTTP,JMS). Enriches and transform data using XSL & domain value mapping lookups. Routes messages based on data in the message payload and/or header and finally and often overlooked feature is that an ESB

ESB:
* ESB (Enterprise Service Bus) implement messaging to enable services to be integrated in a message-based paradigm: both synchronous and asynchronous styles.
* ESB is good for routing messages to multiple destinations. It is also good for doing transformations that have little to no business rules. The footprint is much smaller and incurs minimal overhead therefore the performance is much better.
* ESB virtualizes endpoints that BPEL is orchestrating
* ESB does the heavy lifting of transformations to and from the canonical definition to endpoint definitions of the business objects
* ESB is used for Store and forward transport of data.

BPEL
* Oracle BPEL Process Manager provides a comprehensive, standards-based and easy to
use solution for creating, deploying, and managing cross-application business
processes with both automated and human workflow steps
* BPEL is used for bringing together multiple services. There is much more functionality and allows implementation of complex business logic.
* BPEL takes care of the stateful, long running, orchestration steps
* BPEL operates on the canonical definitions of your business objects - such that
your BPEL process is clean (minimal transformations, assigns) with the focus on
the basic business logic and related compensatory error-handling logic

BPEL Process

1. Synchronous - Client-> Receive Input --> Callback Client
2. Asynchronous - Client -> Receive Input --> reply Output

Process Activites

Interaction - Receive, Reply, Invoke, (User Task), Pick (plus the onEvent, onMessage and onAlarm event handlers)
Structure - Scope, Sequence, Flow, FlowN
Programming logic - While, Switch ,Terminate, Wait, Catch, Throw
Data manipulation - Transform, Assign
Miscellaneous - Java Embedding, Empty

Oracle ADF - Application development Framework

What is JSF ?
JSF -- Is treated as component, where as JSP is treated as custom tags and java code
Developed through JSR-127
It has always only a post request
Always a page gets submitted to the page itself.

6 phases in JSF life cycle
Restore View --> Apply Request Values --> Process Validation-->
update model-->Invoke applications-->Render response

Backing Bean -- binding, Access to data as well as component
Managed Bean -- value ( Create class file manually), access to only the data and not the component

validation
1. Manual Validation
2. Implict automatic Validation
3. Explicit automatic validation
4. Custom validators

ADF component -- Always client side
JSF Component -- Alwats Server side

Assco -- relationship btw entities
Links -- relationship btw views

First time accessing the jbean jsp file
1. web.xml
Look for Binding filters
2. Binding Context -- object created
CPX
3. Binding container



Localization
All messages in self service would be stored in .properties files as Resource Bundles. On a live environment there would be one property file for each supported locale. All the property files would have the name [_].properties. The baseName is configurable using the configuration parameter "MessageFileBaseName". The properties file for the default locale in the instance would be .properties.
1. Messages without tokens: #{messageBean['']}
2. Messages with one token: "#{adfFacesContext.formatter[messageBean['']][]}"

eg:
FacesContext facesContext = FacesContext.getCurrentInstance();
MessageBean message = ((oracle.apps.tks.base.view.util.MessageBean)
facesContext.getApplication().getVariableResolver().resolveVariable
(facesContext,"messageBean"));
MessageFormat form = new MessageFormat(message.get("MSG_WITH_TWO_PARAMS"));
return form.format(testArgs);

Introduction to OA Framework page Personalization

Abstract
This article identifies how Oracle Application (OA) framework pages can be personalized.

Introduction
You can personalize the layout of the Oracle Application (OA) user interface and the content it displays to suit your business needs or user preferences.

You personalize pages to customize users' view of them, rather than to extend the functionality of an application. You can't, for example, add a new region to an existing page, modify business logic, such as data validation, or build new pages using personalization. To do this, you need to create extensions using Oracle 9i JDeveloper with OA Extension.


Benefits of personalizations
Personalizing pages in the OA framework enables you to cater for site-wide and user-specific needs at several levels.

Benefits of page personalizations in the OA framework are that

* they survive upgrades and patches
* administrators can apply personalizations on any component
* users can apply personalizations on queries
* administrators can easily disable personalizations for debugging
* personalizations can be implemented on a test system, for testing prior to deployment
* personalizations can be translated

You save OA framework-based pages as page definitions, for which the database stores metadata. At runtime, a page definition is layered over the base page it personalizes, leaving the original page unchanged.

Personalization levels
Personalizations may occur at the administrator or user level, or be seeded by Oracle application developers.

Administrator-level personalizations
At the administrator level, all OA framework-based pages can be personalized by default. However, administrators can't personalize programmatically created pages or regions, or pages or regions for which the application developer has explicitly disabled administrator personalization.

Administrators may personalize pages, for example, by

changing text for labels, prompts, and tip messages
hiding or showing components
reordering components
restricting query results
adding items, such as fields, buttons, links, pick lists, or images
structuring graphs and charts
seeding end-user views
specifying whether fields are required
changing the destination of hyperlinks

The extent to which an administrator can personalize page flow is limited, and depends on how the flow was implemented. In some cases, you can modify function URLs and personalize the destination URLs that display as navigational elements. Page flow changes are generally beyond the scope of systems administrators, however, because such changes may affect transaction flows, and need thorough testing.

Administrators can personalize OA framework pages at the following levels:
function
location
site
organization
responsibility

As an administrator, you can define personalizations at the function level to determine which users can access specific functions, and when. For example, you can hide the salary field from a user updating an employee record, but display it when the user creates a new employee.

At the location level, you can use locales as the context for personalization – for example, to show different address field labels based on users' country settings.

Site-level – or global – personalizations apply to all users with access to a given application component, such as "setting the number of rows shown in a table."

Organization-level personalizations apply only to users in a specified organization or business unit. You can use organization-level personalizations, for example, to stipulate that notifications be sorted by age for one organization and by urgency for another.

Personalizations at the responsibility level display only to users under a specific responsibility. You may, for example, configure a trend graph to display only to users under the sales manager responsibility.

The level at which an administrator configures personalization settings determines their precedence over other settings. For example, a responsibility-level personalization takes precedence over site-level personalizations for users with the specified responsibility. Users at the site who are not using the relevant responsibility would see only the site-level changes.

User-level personalizations
Default user personalizations, or user views, can exist at three levels. They can be seeded by Oracle developers, created by a system administrator, or created by the end user.

End users can access the personalization user interface by clicking the Save View or Personalize button. They can then personalize inquiry pages using query regions to create specific data views. For example, they can

create and save searches
configure table column titles
hide or show columns
reorder columns
add data filters
change sort orders

Oracle-seeded levels
Oracle 11i E-Business Suite developers can seed personalizations – or build them into – Oracle applications. Seeded function and user-level personalizations, which are like the function and user levels available to administrators and users, respectively, can only be changed or deleted by Oracle customer administrators. However, system administrators or users may duplicate functions and then alter them using personalization settings.

Seeded function personalizations may, for example, provide applications with customized
menus and responsibilities
cascading style sheets (CSS)
FND messages and lookups
icons and images
other required business or user personalizations

OA developers can create and ship seeded personalizations at any administrator personalization level, but system administrators at the customer site can change or delete these settings.

Translating and Deploying Personalizations
You should create personalizations in a test environment before deploying them to one or more production environments, and you should always create initial personalizations in the base language of the application instance.

To export a small number of personalization translations, you use the Export or Upload Translations buttons on the Manage Personalization Levels page. To import or export personalizations in bulk, you use the Export tool to obtain XML files. Because XLIFF (.xlf) files support translations, you then use the XLIFF Extractor to extract translation information from the page XML files.

Finally, you use the XLIFF Importer to load translations into the database repository. Personalizations are stored as documents in the MDS Repository.

Summary
Administrators and end users can personalize pages in the Oracle Application (OA) framework to meet their needs and preferences. Administrators can create, translate, and deploy page personalizations at the function, location, site, organization, and responsibility levels. End users can personalize inquiry pages. Personalized page definitions are stored in the Oracle database, and don't alter the base pages to which they apply.

1. Order Entry
This is first stage, When the order is entered in the system, it basically creates a record in order headers and Order Lines table.

oe_order_headers_all (Here the flow_status_code as entered)
oe_order_lines_all (flow_status_code as entered) ( order number is generated)

2.Order Booking
This is next stage , when Order is booked then the Flow status changed from Entered to Booked. At this stage ,these below table get affected.

oe_order_headers_all (flow_status_code as booked ,booked_flag updated)
oe_order_lines_all (flow_status_code as awaiting shipping,booked_flag updated)
wsh_new_deliveries (status_code OP open)
wsh_delivery_details (released_status ‘R’ ready to release)
Same time, Demand interface program runs in background And insert into inventory tables mtl_demand

3. Reservation
This step is required for doing reservations SCHEDULE ORDER PROGRAM runs in the background and quantities are reserved.Once this program get successfully get completed , the mtl_reservations table get updated.

4. Pick Release
Ideally pick release is the process which is defined in which the items on the sales order are taken out from inventory. Normally pick release SRS program runs in background . Once the program get completed these are the table get affected:

oe_order_lines_all (flow_status_code ‘PICKED’ )
wsh_delivery_details (released_status ‘S’ ‘submitted for release’ )
mtl_txn_request_headers
mtl_txn_request_lines
(move order tables.Here request is generated to move item from saleble to staging sub inventory)
Mtl_material_transactions_temp (link to above tables through move_order_header_id/line_id

5.Pick Confirm
Items are transferred from saleble to staging Subinventory.

mtl_material_transactions
mtl_transaction_accounts
wsh_delivery_details (released_status ‘Y’‘Released’ )
wsh_delivery_assignments

6.Ship Confirm
Here ship confirm interface program runs in background . Data removed from wsh_new_deliveries

oe_order_lines_all (flow_status_code ‘shipped’)
wsh_delivery_details (released_status ‘C’ ‘Shipped’)
mtl_transaction_interface
mtl_material_transactions(linked through Transaction source header id)
mtl_transaction_accounts
Data deleted from mtl_demand,mtl_reservations
Item deducted from mtl_onhand_quantities

7.Enter Invoice
This is also called Receivables interface, that mean information moved to accounting area for invoicing details. Invoicing workflow activity transfers shipped item information to Oracle Receivables.

ra_interface_lines_all (interface table into which the data is transferred from order management)Then Autoinvoice program imports data from this table which get affected into this stage are recievables base table.

ra_customer_trx_all (cust_trx_id is primary key to link it to trx_lines table and trx_number is the invoice number)
ra_customer_trx_lines_all (line_attribute_1 and line_attribute_6 are linked to header_id (or order number) and line_id of the orders)

8.Complete Line
In this stage order line leval table get updated with Flow status and open flag.

oe_order_lines_all (flow_status_code ‘shipped’, open_flag “N”)

9.Close Order
This is last step of Order Processing . In this stage only oe_order_lines_all table get updated. These are the table get affected in this step.

oe_order_lines_all (flow_status_code ‘closed’,open_flag “N”)

These are the typically data flow of a order to cash model for a
standard order.

OM fulfillment model

Ship from Stock
Make to Order
Internal Order
Back-to-Back Order
configure to Order - ATO, PTO
Drop ship to Customer