Creating a Form-Based login page in JSP/Servlet

>>  Creating a Form based login page in JSP

OPSS Artifacts life cycle in an ADF Application

When you enable security in an ADF application, you see a couple of new artifacts in your JDeveloper workspace, namely jps-config.xml, jazn-data.xml and cwallet.sso.

Have you ever wondered what their purpose is, their life cycle and how they relate to WLS domain security configuration? This article is just about it.

As you might know, secured ADF applications leverage OPSS (Oracle Platform Security Services). OPSS is a fundamental component within Oracle Fusion Middleware security. It works as an abstraction layer on top of security services providers, shielding applications from all the complexities in dealing with them. For instance, applications can transparently switch between file-based and LDAP-based policy stores. Likewise for credential store services.

Let's take a closer look at each of those artifacts and their life cycles.

jps-config.xml

This file can be seen as the lookup services registry for OPSS. Among these services are login modules, authentication providers, authorization policy providers, credential stores and auditing services. 
Whenever an OPSS-enabled application requires security services, it looks up a JPSContext object where all the necessary services are supposedly configured.

In ADF applications, a workspace-level jps-config.xml is created once ADF security is enabled. It drives services lookup for ADF's BC (Business Components) Tester available in JDeveloper, which is a JavaSE application. If you want to have security unit tests, you can also easily leverage it.

It is never used once the ADF application gets deployed in a WLS container, even though it is packaged in the ear file. Within a WLS container, a jps-config.xml in /config/fmwconfig is used by all applications in all servers deployed in that WLS domain. There's no such concept of an application-level or server-level jps-config.xml.

jazn-data.xml

This file keeps users, groups and authorization policies for OPSS-enabled applications and is automatically created once ADF security is enabled. I've already covered users and groups life cycles in a previous article. It is important to mention that users and groups are also leveraged by ADF's BC Tester and can be integrated into security unit tests as well.

Authorization policies are, if not the most, one of the most sensitive parts of a secured ADF application, since it governs who has access to what. As you might guess, they are also leveraged by ADF's BC Tester. When the ADF application is deployed into WLS, at startup time, policies are OOTB (Out-Of-The-Box) migrated into the configured policy store, who, by default, is a file called system-jazn-data.xml, located under /config/fmwconfig. You can configure how (and if) policies are migrated through some properties in weblogic-application.xml. Here they are:

<listener>

<listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener<listener-class>

<listener>

This listener is the one actually responsible for pushing the changes to the runtime policy store. Make sure it is present in weblogic-application.xml. Otherwise, you’ll experience a lot of frustration in trying to deploy authorization policies along with your application.

<application-param>

<param-name>jps.policystore.migration</param-name>

<param-value>[MERGE|OVERWRITE|OFF]</param-value>

</application-param>

MERGE, OVERWRITE and OFF are exclusive and applicable for deployments and redeployments. And they mean exactly what you might be thinking.

• MERGE will merge what’s already available in the runtime policy store. This might be particularly useful in some advanced deployments where more than one application share the same application policy stripe.
• OVERWRITE wipes away the existing application policy stripe and load all policies from scratch.
• OFF skips policy migration.

Do notice that once the application is undeployed, its policies are also removed from the policy store, unless you set the following property in weblogic-application.xml:

<application-param>

<param-name>jps.policystore.removal</param-name>

<param-value>OFF</param-value>

</application-param>

Authorization policies migration will always happen according to weblogic-application.xml configuration, no matter what the deployment method is.

cwallet.sso

This file keeps credentials used by the application. A subtle and fundamental distinction is important to be made here: credentials and identities are not the same thing. Simply put, in OPSS, identities are what authentication requests are done against, while credentials are securely kept objects that are somehow presented to authentication providers to be matched against identities. 

cwallet.sso is encrypted and you cannot browse it or explicitly edit it via JDeveloper. At design-time, different components make use of cwallet.sso and are responsible for creating the necessary credentials in it. Examples are OWSM policy attachments that override the csf-key and ADF connections requiring credentials in the call out.

If you need credentials that can’t be created within JDeveloper, you can either use wlst createCred online command or write some code using OPSS APIs. Both options makes the whole life cycle story a little catchy, because a running WLS container is necessary. You can also disable credentials migration and create them directly in the WLS domain where applications are deployed. 

Like authorization policies, credentials are also OOTB migrated into the configured WLS domain credential store on application startup. By default, the credential store is the cwallet.sso file in /config/fmwconfig folder.

The following weblogic-application.xml properties govern how (and if) they're deployed.

<listener>

<listener-class>oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener</listener-class>

</listener>

As for policies, the same listener migrates credentials. Avoid frustration and make sure the listener is present if you want to migrate or control how your credentials are migrated.

<application-param>

<param-name>jps.credstore.migration</param-name>

<param-value>[MERGE|OVERWRITE|OFF]</param-value>

</application-param>

• MERGE: migrate non-existing credentials only;
• OVERWRITE: overwrites existing credentials;
• OFF: skips credentials migration;

RESTful Services with Oracle Service Bus

 Recently I was asked about REST (see http://en.wikipedia.org/wiki/Representational_State_Transfer)

support in Oracle Service Bus. OSB 10gR3 has full support for REST and

implementing a REST approach in a proxy service is very simple. In this

example, we will create a proxy service that provides a REST interface to a

product catalog.

Why use OSB for REST?

Using the Oracle Service Bus to provide an interface as

simple as REST may seem odd at first. There are several good reasons for this

approach though.

1. You automatically get all of the monitoring, reporting, security and more provided
   by OSB for your RESTful services


2. You keep the benefits of mediation. For example, of our company in this example
   purchased another company that provided different products, you could use the
   OSB to act as a façade over both product catalogs while providing a single,
   unchanged REST interface.


3. You
   can REST-ify existing, non-service enabled assets like EJBs

The Products Proxy Service

Let's get started. First we will create a new OSB

Configuration Project to house our REST services. I named the configuration

project RESTConfig in the sample source code. You can download

the sample source code here.

Inside of the RESTConfig project I then

created a standard OSB project named SimpleREST. Once the OSB

project was created, I was ready to start creating my REST project.

Next I created a proxy service named Products.

I used the default endpoint URI of SimpleREST/Products but in a

production environment you'll most likely want to customize that. Be sure to

define your proxy service as an Any XML Service so you can accept

and return XML of any flavor.

Now it is time to create our message flow. Here is where

it gets interesting. One of the fundamental concepts in REST is the use of the

native HTTP methods to allow the service consumer to express their intent. The

specific HTTP methods that we are interested in are: GET, POST, PUT, HEAD,

OPTIONS and DELETE. In this example I don't make use of the TRACE method.

However, you will be able to add that to your projects easily after reading

this.

The handling of each of those methods is different, so we

begin our message flow with a Conditional Branch node (see figure 1). I added a

branch for each of the methods I was interested in. In the Conditional Branch

node I set the XPath field to ./ctx:transport/ctx:request/http:http-method/text()

and theIn Variable field to inbound. This is the equivalent to the XPath

expression $inbound/ctx:transport/ctx:request/http:http-method/text().

The text() operation at the end is important because I

want to deal with the method in its plain text form and not as an XML

expression.

Figure 1 Standard OSB REST Pattern

When adding the branches it is important to enclose the

contents of the Value field in single quotes (Figure 2) to denote it is a

string value. If you forget this, you will get an error about an unbound XML

node when you run the proxy service because OSB will treat the contents of the

Value field as a variable instead of a string literal.

Figure 2 Don't forget the quotes!

For each branch, add a pipeline pair and name it

appropriately, as shown in figure 1. Before we fill in the GET Pipeline with

the necessary logic, let's take a moment to decide how we want the HTTP GET method

to be handled. Ideally, we want to be able to point a web browser or other REST

service consumer to a URL like: http://localhost:7001/SimpleREST/Products/id=# to

retrieve a product representation by its ID. Since the proxy service is

listening at http://localhost:7001/SimpleREST/Products,

the remainder of the URL (i.e. the id=#) will be accessible in the message

flow as the relative-URI part of the $inbound variable.

The GET Method

Now that we know what the URL should look like for a GET,

we can fill in the logic. In the GET Pipeline (Figure 3) we will add two Assign

actions. The first Assign action will get the first part of the relative URL

(i.e. the id part). We won't do anything

with this part in this example, but you can use this technique to ensure that

the URL used had the correct format. The expression to use in the first Assign

statement is as follows:

fn:tokenize(data($inbound/ctx:transport/ctx:request/http:relative-URI),

'=')[1]

This expression will take the relative-URL value and

tokenize it using the '=' character, returning the first token. So if the

relative-URI is "id=27" this expression will return the "id" string. Why XPath

counts from 1 instead of 0 I don't know. Set the Variable field to attr and you are

done with the first Assign statement.

The second Assign statement is very similar to the first,

except we are retrieving the second part of the relative-URI. Its expression is

as follows:

fn:tokenize(data($inbound/ctx:transport/ctx:request/http:relative-URI),

'=')[2]

Set the Variable field to productID. In the sample code I include

a Log statement to output the contents of these variables to the console

Figure 3 The GET Pipeline

In the Response Pipeline we will construct our response

message for the GET. We will just mock up a product document for this tutorial.

The following code snippet (which you will put into the Expression field

of the Replace action) shows the value that the Replace action will put into

the $body

variable, which is then returned to the caller.

{$productID}

Foobar

19.99

Listing 1 Constructing the response document

Set the XPath field to just a period (.) and be

sure to select the Replace Node Contents  radio button. If you deploy

the project you can test it using your web browser. Assuming your OSB server is

running on the default port 7001, you can use the following URL:

http://localhost:7001/SimpleREST/Products/id=2

Your web browser should show you the following:

2

Foobar

19.99

Note: Capitalization counts even with REST

Alternatively, you can use the OSB Test Console instead of

a web browser. I recommend using the Test Console (Figure 4) because it gives

you more control over the service call and visibility into the message flow. To

test the GET method, right-click on the Products.proxy file in the

Workshop IDE and select Debug As -> Debug on Server.... When the Test

Console appears, click on the down-arrow icon in the Transport section. This

will allow you to set the relative-URI and http-method fields directly.

Figure 4 The Transport section of the Test Console

When you are happy with your settings, press the Execute

button to run the test. The Test Console (Figure 5) will return the results and

provide you with the response metadata and the invocation trace, which is

useful when debugging your proxy services.

Figure 5 The Test Console response

Now that we have the GET branch taken care of. Let's take

a quick look at the other HTTP methods that we are supporting.

The POST Method

The HTTP POST method is traditionally used with REST to

create new entities. The message content that is POSTed can be in XML format, or

in the format used by HTML forms, which is still the most common mechanism for

submitting data to a web site in use today. However,, I highly recommend that

you keep your information in XML format instead of the HTML Form format simply

because the HTML Form only  supports the GET and POST verbs, whereas with REST

we also want to use the other verbs, like PUT and DELETE.

The POST Pipeline shows how to handle the POST method. It's

pretty simple in that it extracts the specific information it wants from the

$body and then creates and returns an XML representation, simulating the

creation of a product. You can use the OSB Test Console to test this method by

setting the http-method field to post and then typing in the payload as

follows:

Widget

99.99

The two Assign statements in the POST Pipeline simply

extract the name and price information and return a representation of the new

product, with a hard-coded ID of 777

The PUT Method

The PUT method is used to update an entity. It operates

very much like the POST method does, except this method will expect to see the

ID in the submitted product representation. You can test this operation in

pretty much the same way that you tested the POST, just change the http-method

to PUT and use the following as your payload:

999

Widget

99.99

Here we will add a little error checking to ensure that

the ID for the product has been specified. The If-Then action (Figure 6) uses

the expression: exists($body/Product/ID) to test

for the presence of the ID element.

Figure 6 The PUT Pipeline

If the ID element is defined, we then use a single Assign

statement to create our entire response document as follows:

{$body/Product/ID/text()}

   {$body/Product/Name/text()}

   {$body/Product/Price/text()}

If the ID element is missing from the $body, then we throw

an error to alert the service consumer of the problem. In the response pipeline

we simply set $body

to the value of $responseDoc, what was created in our Assign statement.

The HEAD Method

The HEAD method is used to return metadata about a

representation to the caller. It's called the HEAD method because the metadata

is returned in the HTTP headers. This metadata can be anything you want it to

be, but a good place to start is the standard HTTP headers used by the

Inbound-Response to the Inbound-Request. Figure 6 shows the message flow for

HEAD Pipeline (Figure 7). All we do is populate the data of a single Transport

Header action in the response pipeline.

Figure 7 Implementing the HEAD method

Its up to you and your specific needs to define which

headers you want to send back for the HEAD method, but I recommend sending at

least the HTTP Content-Type header with a value along the lines of 'text/xml; charset=utf-8'.

This will help the HTTP clients know how to parse the text that is returned.

Setting the Connection header to 'keep-alive' is also generally a good idea.

The OPTIONS Method

Finally, the OPTIONS method is used to convey to the

caller which HTTP methods are appropriate for the Products entity. In this

case, all we need to do is to specify a Transport Header for the outbound

response (see figure 8).

Figure 8 Implementing the OPTIONS Pipeline

Configure the Transport Header as shown in figure 9.

Figure 9 Transport Header Settings

The expression for the header is 'GET, HEAD, PUT, DELETE, OPTIONS'. It

may not be necessary to add the OPTIONS clause, since you have to call it in order to get

the response in the first place, but I show it for completeness. That covers

the basics of using OSB to implement RESTful service patterns. As you can see,

it's quick and simple to do. Using this technique you can wrap any

functionality in your enterprise using a REST service interface.

The DELETE Method

The DELETE method is very straight forward. It expects to

have a product ID specified on the URI and it simply deletes the product with

that ID. Due to its trivial nature, it is not implemented in the sample code.

Calling RESTful Services from OSB

In addition to providing a REST interface, OSB can also

invoke REST services. For this part of the exercise we will provide a standard

SOAP interface to OSB. OSB will then take those SOAP calls and invoke the REST

services accordingly. The WSDL for our SOAP interface defines the following

operations:

getProductDetail(productID)

createProduct(name)

updateProduct(productID)

deleteProduct(productID)

Each of these operations will be performed by the REST

services we created earlier in this tutorial.

We begin by creating a proxy service named CallREST based

on the Products.wsdl file (in the WSDL folder of the SimpleREST project). Since

the WSDL defines several SOAP operations, we start the message flow with an

Operational Branch node, and create branches for each of the operations we want

to handle. Once that is done, add a Pipeline Pair to the getProductDetail

branch, as show in Figure 10.

Figure 10 The basic structure for the CallREST message flow

The getProduct Pipeline consists of a single Stage

node, as shown in Figure 11. The initial Assign statement is used to extract

the product ID from the request document and store it in the $productID

variable. The next node is a Service Callout

Figure 11 The getProduct Pipeline stage

The Service Callout (Figure 12) is where most of the work

is done. To configure the Service Callout, be sure to check the Configure

Payload Document radio button since REST does not use a SOAP format. Set the Request

Variable field to requestBodyDocument

and the Response Variable field to responseBodyDocument. That's all you need to do for the Service Callout action.

Figure 12 Service Callout contents

The first action is a Transport Header. Configuring this

action is simple. Set the Direction field to Outbound Request.

Also, be sure to check the Pass all Headers checkbox.

Immediately after the Transport Header action are two

Insert actions. The first insert action (Figure 13) is used to specify the HTTP

GET method. Configure it as shown in Figure 13 

Figure 13 Specifying the HTTP GET method

The second and last Insert action (Figure 14) in the

request pipeline shows how to specify the relative-URI of the request. The expression:

id={$productID}

is used to create the value of the relative-URI of the outbound request

variable.

Figure 14 Specifying the Relative-URI of the request

At this point our request of the REST service is properly

formatted. Once the REST service is invoked, the response will be returned to

our message flow in the responseBodyDocument

variable. In the Response Action pipeline of the service callout, we add a

single Replace action (see Figure 15) to take the response document from the

REST service and format it to meet the needs of our SOAP operation.

Figure 15 Formatting the that our operation returns

The remaining branches follow a similar pattern so there

is no need to document them here. If you want to see the sample code for this

blog entry, you can download it from here:

Download Source

Conclusion

As you can see from this sample, it is very easy to use

Oracle Service Bus to both call existing REST services, and to have OSB provide

a REST interface to existing SOAP services. The benefit of REST is the

simplicity of the interface design. By marrying OSB and REST, you get the

simplicity of REST, while maintaining the ability to define SLA's on each

service or operation, maintain visibility over these operations using OSBs

built in monitoring and reporting, and still retaining the necessary agility by

being able to quickly alter the OSB message flows and aggregating/orchestrating,

multiple services in the "backend" without the implicit knowledge of the

service consumer.

Oracle APPS Adapter Usage

Here I am giving one usage of Apps adapter scenario which can use Interface tables and views in Oracle EBS.

Interface Tables

Adapter for Oracle Applications use open interface tables to insert data in Oracle Applications. For example, by using interface tables, you can insert a purchase order into Oracle Applications to generate the sales order automatically. Data is never loaded directly into Oracle Applications base tables. Instead, data is first loaded into interface tables, and then Oracle-supplied concurrent programs move data from interface tables to base tables. This ensures that all business logic and processing is handled using Oracle components.
Adapter for Oracle Applications use open interface tables to integrate with Oracle Applications through direct database access. The Adapter for Oracle Applications inserts data into the open interface tables. These interface tables can be used only for insert operations and support only an inbound connection into Oracle Applications.

Interface tables are intermediate tables into which the data is inserted first. Once the data gets inserted into the interface tables, the data is validated, and then transferred to the base tables. Base tables are real application tables that reside in the application database. The data that resides in the interface tables is transferred to the base tables using concurrent programs. A concurrent program is an instance of an execution file. Concurrent programs are scheduled in Oracle Applications to move data from interface tables to base tables. These programs perform the application-level checks and run validation before inserting data into base tables.

Views

Adapter for Oracle Applications uses views to retrieve data from Oracle Applications. For example, by using views, you can retrieve information about your customers from the required tables in Oracle Applications.

Adapter for Oracle Applications uses views to retrieve data from Oracle Applications. Views allow only simple definition. By using views, you can get synchronous data access to Oracle Applications. In Adapter for Oracle Applications, views are created on base tables as well as interface tables. These views can be used only for select operations.

In the Oracle Applications 11.5.10 release, you cannot work on multiple views. A work around to address this would be to create a view that spans multiple views.

Design-Time Tasks for Interface Tables

This section describes how to configure the Adapter for Oracle Applications to use interface tables. It describes the steps to configure Adapter for Oracle Applications using the Adapter Configuration Wizard in Oracle JDeveloper.

BPEL Process Scenario

Take Open Interface tables (OE_HEADER_IFACE_ALL and OE_LINES_IFACE_ALL) as examples.

When a request of inserting order data into Open Interface tables is received, order details will be retrieved through synchronous read operation from an input file and then inserted into Open Interface tables (OE_HEADER_IFACE_ALL and OE_LINES_IFACE_ALL).

If the BPEL process is successfully executed after deployment, you can validate the result by fetching the inserted data using SQL statement.

Prerequisites to Configure Interface Tables

• Define primary keys on all the interface tables being used.
• Define parent-child relationships among all the selected interface tables.

BPEL Process Flow

Following is a list of the procedures required to accomplish the design-time tasks.

1. Create a new BPEL project.
2. Add a partner link.
3. Add a partner link for File Adapter.
4. Configure the Invoke activities.
5. Configure the Assign activity.

Creating a New BPEL Project

To create a new BPEL project

1. Open JDeveloper BPEL Designer. Click New Application in the Application Navigator.
   The Create SOA Application - Name your application page is displayed.
   The Create SOA Application - Name your application Page
   
2. Enter an appropriate name for the application in the Application Name field and select SOA Application from the Application Template list.
   Click Next. The Create SOA Application - Name your project page is displayed.
3. Enter an appropriate name for the project in the Project Name field. For example, InsertOrder.
   The Create SOA Application - Name your project Page
   
4. In the Project Technologies tab, ensure that SOA is selected from the Available technology list to the Selected technology list.
   Click Next. The Create SOA Application - Configure SOA settings page is displayed.
   The Create SOA Application - Configure SOA settings Page
   
5. In the BPEL Process Name field, enter a descriptive name. For example, InsertOrder.
6. Select Composite With BPEL from the Composite Template list, and then click Finish. You have created a new application, and an SOA project. This automatically creates an SOA composite.
   The Create BPEL Process page is displayed.
7. Enter an appropriate name for the BEPL process in the Name field. For example, InsertOrder.
   Select Asynchronous BPEL Process in the Template field. Click OK.
   An asynchronous BPEL process is created with the Receive and Reply activities. The required source files including bpel and wsdl, using the name you specified (for example, InsertOrder.bpel and InsertOrder.wsdl) and composite.xml are also generated.

Adding a Partner Link

This section describes how to add a partner link to your BPEL process. A partner link defines the link name, type, and the role of the BPEL process that interacts with the partner service.

To add a partner link to insert order details into selected Open Interface tables

1. Click BPEL Services in the Component palette.
   Drag and drop Oracle Applications from the BPEL Services list into the right Partner Link swim lane of the process diagram. The Adapter Configuration Wizard Welcome page appears. Click Next.
2. Enter a service name in the Service Name field. For example, InsertOrder.
   Click Next. The Service Connection dialog appears.
   Specifying a Database Service Connection
   
3. You can perform either one of the following options for your database connection:
   
   Note: You need to connect to the database where Oracle Applications is running.
   
   
   • You can create a new database connection by clicking the Create a New Database Connection icon.
     How to define a new database connection, see Create a New Database Connection.
   • You can select an existing database connection that you have configured earlier from the Connection drop-down list.
     The Service Connection page will be displayed with the selected connection information. The JNDI (Java Naming and Directory Interface) name corresponding to the database connection appears automatically in the Database Server JNDI Name field. Alternatively, you can specify a JNDI name.
     
     Note: When you specify a JNDI name, the deployment descriptor of the Oracle Applications adapter must associate this JNDI name with configuration properties required by the adapter to access the database.
     
     The JNDI name acts as a placeholder for the connection used when your service is deployed to the BPEL server. This enables you to use different databases for development and later for production.
     
     Note: For more information about JNDI concepts, refer to Oracle Fusion Middleware User's Guide for Technology Adapters.
     
4. Click Next in the Service Connection dialog box. You can add an interface table by browsing through the list of interface tables available in Oracle Applications.
   For Oracle E-Business Suite Release 12:
   If you are connecting to Oracle E-Business Suite Release 12, then the IREP File not present dialog box appears indicating that Adapter could not find the Oracle Integration Repository data file corresponding to the database you are connecting in your workspace. Absence of the data file would make browsing or searching of Integration Repository tree considerably slow. You can choose to extract the data file and create a local copy of the Integration Repository data file. Once it is created successfully, Adapter will pick it up automatically next time and retrieve data from your local Integration Repository.
   You can select one of the following options:
   
   • Click Yes to extract the Integration Repository data file.
     Extracting Integration Repository Data File
     
     After the system successfully creates a local copy of the Integration Repository data file, next time when you connect to the database, you will find the IRep Data File field appears in the Operation dialog box indicating where your local copy exists with the creation date and time as part of the file name.
     Using the Local Integration Repository Data File
     
   • Click No to query the Integration Repository data file from the live database you are connecting to display the Integration Repository tree.
     
     Note: It is highly recommended that you create a local copy of the Integration Repository data file so that Adapter will query the data next time from the local copy in your workspace to enhance the performance.
     
   For Oracle E-Business Suite pre-Release 11.5.10:
   If you are connecting to a pre-11.5.10 Oracle Applications instance, you must select the interface type in the Adapter Configuration Wizard. Select Tables/Views/APIs/Concurrent Programs to proceed.
5. Click Get Object to open the Oracle Applications Module Browser.
   Selecting a Concurrent Program from the Module Browser
   
   Oracle Applications Module Browser includes the various product families that are available in Oracle Applications. For example, Applications Technology or Order Management Suite are product families in Oracle Applications. The product families contain the individual products. For example, Order Management Suite contains the Order Management product. The individual products contain the business entities associated with the product. For example, the Order Management product contains the Sales Order business entity.
   Business entities contain the various application modules that are exposed for integration. These modules are grouped according to the interface they provide. concurrent programs can be found under the Open Interfaces category.
6. Navigate to Order Management Suite (OM_PF) > Order Management (ONT) > Sales Order (ONT_SALES_ORDER) > OpenInterfaces >Order Management Sales Orders Open Interface (OEOIMP) > Tables to select OE_HEADERS_IFACE_ALL.
   
   Note: You can also search for a table by entering the name of the program in the Object Name field. Select the Tables check box, then click Search.
   
   Click OK. The Application Interface page appears with the selected open table.
   Adapter Configuration Wizard - Application Interface Page
   
7. Click Get Object to open the Oracle Applications Module Browser again to select another open interface table OE_LINES_IFACE_ALL using the same navigation path Order Management Suite (OM_PF) > Order Management (ONT) > Sales Order (ONT_SALES_ORDER) > OpenInterfaces >Order Management Sales Orders Open Interface (OEOIMP) > Tables.
   Click OK. The Application Interface page appears with the two selected tables.
   Adapter Configuration Wizard - Application Interface Page
   
   Click OK.
8. Click Next. The Operation Type page is displayed.
   Adapter Configuration Wizard - Operation Type Page
   
   Select the Perform an Operation on a Table radio button and then choose the Insert check box. Ensure that the Select check box is deselected.
9. Click Next. The Select Table page appears which displays the tables that have been previously imported in this JDeveloper project (including tables that were imported for other partner links). This enables you to reuse configured table definitions in multiple partner links.
   Adapter Configuration Wizard - Select Table Page
   
   Select OE_HEADERS_IFACE_ALL as the root database table for this service's query.
10. Click Next. The Define Primary Keys page is displayed.
    Adapter Configuration Wizard - Define Primary Keys Page for OE_HEADERS_IFACE_ALL
    
    Select the following primary keys for the OE_HEADERS_IFACE_ALL table:
    
    • ORDER_SOURCE_ID
    • ORIG_SYS_DOCUMENT_REF
    Click Next.
    Select the same primary keys for the OE_LINES_IFACE_ALL table.
    Adapter Configuration Wizard - Define Primary Keys Page for OE_LINES_IFACE_ALL
    
11. Click Next. The Relationships page appears. Click Create to open the Create Relationship dialog.
    Defining Relationships
    
    Enter the following information to define the relationship between the header and the detail table:
    
    • Select the OE_HEADERS_IFACE_ALL as the parent table and OE_LINES_IFACE_ALL as the child table.
    • Select the mapping type: OE_HEADERS_IFACE_ALL has a 1:M Relationship with OE_LINES_IFACE_ALL
      
      Note: If foreign key constraints between tables already exist in the database, then two relationships are created automatically while importing tables. One of the relationships is 1:M relationship from the source table, which is the table containing the foreign key constraints, to the target table. The other relationship is a 1:1 back pointer from the target table to the source table.
      
    • Select the Private Owned check box.
    • Associate the foreign key fields with the primary key fields:
      
      • OE_HEADERS_IFACE_ALL.ORDER_SOURCE_ID: ORDER_SOURCE_ID
      • OE_HEADERS_IFACE_ALL.ORIG_SYS_DOCUMENT_REF: ORIG_SYS_DOCUMENT_REF
    • The Relationship Name field is populated automatically by default. You can optionally specify a new name for the relationship you are creating.
    Click OK. The newly created relationship information appears in the Relationships page.
    Adapter Configuration Wizard - Relationships Page
    
12. Click Next. The Attribute Filtering page appears. Leave default selections unchanged.
    Adapter Configuration Wizard - Attribute Filtering Page
    
    Click Next. The Advanced Options page appears.
    Click Next.
13. Click Finish. The wizard generates the WSDL file corresponding to the selected interface. This WSDL file is now available for the partner link.
    Completing the Partner Link Configuration
    
14. Click Apply and then OK. The partner link is created with the required WSDL settings.

Adding a Partner Link for File Adapter

Use this step to configure a BPEL process by synchronously reading payload from an input file to obtain the purchase order details.

To add a Partner Link for File Adapter to read order details:

1. In JDeveloper BPEL Designer, click BPEL Services in the Component palette.
   Drag and drop File Adapter from the BPEL Services list into the right Partner Link swim lane before the first partner link InsertOrder. The Adapter Configuration Wizard Welcome page appears.
   Click Next.
2. In the Service Name dialog, enter a name for the File Adapter service, such as getOrderDetails.
3. Click Next. The Adapter Interface page appears.
   Specifying the Adapter Interface
   
   Select the Define from operation and schema (specified later) radio button and click Next.
4. In the Operation page, specify the operation type. For example, select the Synchronous Read File radio button. This automatically populates the Operation Name field.
   Specifying the Operation
   
   Click Next to access the File Directories page.
5. Select the Logical Name radio button and specify directory for incoming files, such as inputDir.
   Ensure the Delete files after successful retrieval check box is not selected.
   Configuring the Input File
   
   Click Next to open the File Name page.
6. Enter the name of the file for the synchronous read file operation. For example, enter order_data.xml. Click Next to open the Messages page.
7. Select the 'browse for schema file' icon next to the URL field to open the Type Chooser.
   Click Type Explorer and select Project Schema Files > InsertOrder_table.xsd > OeHeadersIfaceAllCollection. Click OK.
   The selected schema information will be automatically populated in the URL and Schema Element fields.
   Specifying Message Schema
   
8. Click Next and then Finish. The wizard generates the WSDL file corresponding to the partner link. The main Create Partner Link dialog box appears, specifying the new WSDL file getOrderDetails.wsdl.
   Completing the Partner Link Configuration
   
   Click Apply and OK to complete the configuration and create the partner link with the required WSDL settings for the File Adapter service.
   The getOrderDetails Partner Link appears in the BPEL process diagram.

Configuring the Invoke Activities

After configuring partner links, you need to configure the following two Invoke activities:

1. To get the acknowledgement data by invoking the ViewAck partner link.
2. To write acknowledgement data to an XML file by invoking WriteAckdata partner link for File Adapter.

To add the first Invoke activity for a partner link to get acknowledgement data:

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette. Drag and drop the first Invoke activity into the center swim lane of the process diagram, between the receiveInput and callbackClient activities.
   Adding an Invoke Activity
   
2. Link the Invoke activity to the ViewAck service. The Edit Invoke dialog appears.
3. Enter a name for the Invoke activity, then click the Create icon next to the Input Variable field to create a new variable. The Create Variable dialog box appears.
4. Select Global Variable, then enter a name for the variable. You can also accept the default name. Click OK.
5. Click the Create icon next to the Output Variable field to create a new variable. The Create Variable dialog box appears.
6. Select Global Variable, then enter a name for the variable. You can also accept the default name. Click OK.
   Click Apply and OK in the Edit Invoke dialog box to finish configuring the Invoke activity.
   
   The Invoke activity appears in the process diagram.

To add the second Invoke activity for a partner link to insert order data into Open Interface tables:

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette. Drag and drop the second Invoke activity into the center swim lane of the process diagram, between the first Invoke and callbackClient activities.
2. Link the Invoke activity to the InsertOrder service. The Edit Invoke dialog box appears.
3. Repeat Step 3 and Step 4 described in the first Invoke activity procedure. Click Apply and then OK in the Edit Invoke dialog box to finish configuring the second Invoke activity.
   

Configuring the Assign Activity

The next task is to add an Assign activity to the process map. This is used to pass the output of File Adapter’s Synchronous Read (getOrderDetails) service as an input to the Open InterfaceInsertOrder service.

To add an Assign activity:

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette.
   Drag and drop the Assign activity into the center swim lane of the process diagram, between the first and second Invoke activities that you just created earlier.
2. Double-click the Assign activity to access the Edit Assign dialog.
   Click the General tab to enter a name for the Assign activity. For example, SetOrderDetails.
3. Select the Copy Operation tab, click the 'Plus' sign icon and select Copy Operation from the menu. The Create Copy Operation window appears.
   Specifying a Copy Operation Action
   
4. Enter the following parameter information:
   
   • In the From navigation tree, select type Variable, then navigate to Variable > Process > Variables > Invoke_SynchRead_OutputVariable and select body.
   • In the To navigation tree, select type Variable, then navigate to Variable > Process > Variables > Invoke_insert_InputVariable and select OeHeadersIfaceAllCollection.
     
   • Click OK. The Edit Assign dialog box appears.
5. Click Apply and then OK to complete the configuration of the Assign activity.

Completed BPEL Process Diagram

Click the composite.xml to display the Oracle JDeveloper composite diagram:

Note: Click the Source tab of composite.xml to enter a value for the physical directory inputDir for the reference getOrderDetails (such as /usr/tmp).

/usr/tmp

Run-Time Tasks for Interface Tables

After designing the BPEL process, the next step is to deploy, run, and monitor it.

1. Deploy the BPEL process.
2. Test the BPEL process.

Deploying the BPEL Process

You must deploy the BPEL process before you can run it. The BPEL process is first compiled, and then deployed to the application server (Oracle WebLogic Server) that you have established the connection.

Prerequisites

Before deploying the BPEL process using Oracle JDeveloper, you must ensure the following:

• You must have established the connectivity between the deign-time environment and an application server.
  For more information, see Configuring the Data Source in Oracle WebLogic Server and Creating an Application Server Connection.
• Oracle WebLogic Server has been started.
  Before deploying the BPEL process, you need to start the Oracle WebLogic Server that you have established the connection.
  If a local instance of the WebLogic Server is used, start the WebLogic Server by selecting Run > Start Server Instance from Oracle JDeveloper.
  Once the WebLogic Admin Server "DefaultServer" instance is successfully started, you should find that and DefaultServer started message in the Running:DefaultServer and Messages logs.
  
  

To deploy the BPEL process

1. Select the BPEL project in the Applications Navigator.
2. Right-click the project name. Select Deploy from the menu that appears.
3. Right-click the project name, and then select Deploy > [project name] > [serverConnection] from the menu that appears.
4. The BPEL process is compiled and deployed. You can check the progress in the Messages window.

Testing the BPEL Process

Once the BPEL process is deployed, you can manage and monitor the process from the Oracle Enterprise Manager Fusion Middleware Control Console. You can also test the process and the integration interface by manually initiating the process.

To manually initiate and monitor the BPEL process

1. Navigate to Oracle Enterprise Manager Fusion Middleware Control Console (http://:/em). The composite you deployed is displayed in the Applications Navigation tree.
   
2. Enter username (such as weblogic) and password and click Login to log in to a farm.
   You may need to select an appropriate target instance farm if there are multiple target Oracle Enterprise Manager Fusion Middleware Control Console farms.
3. From the Farm base domain, expand the SOA > soa-infra to navigate through the SOA Infrastructure home page and menu to access your deployed SOA composite applications running in the SOA Infrastructure for that managed server.
   
   Note: The Farm menu always displays at the top of the navigator. As you expand the SOA folder in the navigator and click the links displayed beneath it, the SOA Infrastructure menu becomes available at the top of the page.
   
   Click the SOA composite application that you want to initiate (such as 'OrderInsert') from the SOA Infrastructure.
   Click Test at the top of the page.
4. The Test Web Service page for initiating an instance appears. You can specify the XML payload data to use in the Input Arguments section.
   Enter the input string required by the process and click Test Web Service to initiate the process.
   Testing Web Service
   
   The test results appear in the Response tab upon completion.
5. Click on the BPEL process name and then click the Instances tab. The SOA composite application instance ID, name, conversation ID, most recent known state of each instance since the last data refresh of the page are displayed.
   In the Instance ID column, click a specific instance ID to show the message flow through the various service components and binding components. The Flow Trace page is displayed.
   In the Trace section, you should find the sequence of the message flow for the service binding component (insertorder_client_ep), BPEL component (InsertOrder), and reference binding components (getOrderDetails and InsertOrder). All involved components have successfully received and processed messages.
   If any error occurred during the test, you should find it in the Faults section.
   Flow Trace Page
   
6. Click your BPEL service component instance link (such as InsertOrder) to display the Instances page where you can view execution details for the BPEL activities in the Audit Trail tab.
   Click the Flow tab to check the BPEL process flow diagram. Click an activity of the process diagram to view the activity details and flow of the payload through the process.
7. Validating Records Using SQL
   To confirm that the records have been inserted into the selected Open Interface tables, you can write SQL SELECT statements and fetch the results showing the latest records inserted into the open interface tables.

Design-Time Tasks for Views

This section describes the steps to configure Adapter for Oracle Applications using the Adapter Configuration Wizard in Oracle JDeveloper.

BPEL Process Scenario

In this example, Adapter for Oracle Applications retrieves purchase order acknowledgement information from Interface Views OE_HEADER_ACKS_V and OE_LINE_ACKS_V. The acknowledgement information will then be written to an XML file as an output for confirmation.

If the BPEL process is successfully executed after deployment, you can validate the output XML file with the same order book reference ID once an order is approved.

Prerequisites to Configure Views

You need to define a uniqueness criteria, which could be a single key or composite keys.

BPEL Process Flow

Based on the scenario, the following design-time tasks are discussed in this chapter.

1. Create a new BPEL project.
2. Add a partner link.
3. Add a partner link for File Adapter.
4. Configure the Invoke activity.
5. Configure the Assign activity.

Creating a New BPEL Project

To create a new BPEL project

1. Open JDeveloper BPEL Designer. Click New Application in the Application Navigator.
   The Create SOA Application - Name your application page is displayed.
   The Create SOA Application - Name your application Page
   
2. Enter an appropriate name for the application in the Application Name field and select SOA Application from the Application Template list.
   Click Next. The Create SOA Application - Name your project page is displayed.
3. Enter an appropriate name for the project in the Project Name field. For example, WriteAck.
   The Create SOA Application - Name your project Page
   
4. In the Project Technologies tab, ensure that SOA is selected from the Available technology list to the Selected technology list.
   Click Next. The Create SOA Application - Configure SOA settings page is displayed.
   The Create SOA Application - Configure SOA settings Page
   
5. In the BPEL Process Name field, enter a descriptive name. For example, WriteAck.
6. Select Composite With BPEL from the Composite Template list, and then click Finish. You have created a new application, and an SOA project. This automatically creates an SOA composite.
   The Create BPEL Process page is displayed.
   The Create BPEL Process Page
   
7. Enter an appropriate name for the BEPL process in the Name field. For example, WriteAck.
   Select Asynchronous BPEL Process in the Template field. Click OK.
   An asynchronous BPEL process is created with the Receive and Reply activities. The required source files including bpel and wsdl, using the name you specified (for example, WriteAck.bpel and WriteAck.wsdl) and composite.xml are also generated.

Adding a Partner Link

A BPEL partner link defines the link name, type, and the role of the BPEL process that interacts with the partner service.

In the scenario described earlier, you need to add a partner link to retrieve order acknowledgement information from selected Open Interface Views.

To add a partner link

1. Click BPEL Services in the Component palette.
   Drag and drop Oracle Applications from the BPEL Services list into the right Partner Link swim lane of the process diagram. The Adapter Configuration Wizard Welcome page appears. Click Next.
2. Enter a service name in the Service Name field. For example, ViewAck.
   Click Next. The Service Connection dialog appears.
   Specifying a Database Service Connection
   
3. You can perform either one of the following options for your database connection:
   
   Note: You need to connect to the database where Oracle Applications is running.
   
   
   • You can create a new database connection by clicking the Create a New Database Connection icon.
     How to define a new database connection, see Create a New Database Connection.
   • You can select an existing database connection that you have configured earlier from the Connection drop-down list.
     The Service Connection page will be displayed with the selected connection information. The JNDI (Java Naming and Directory Interface) name corresponding to the database connection appears automatically in the Database Server JNDI Name field. Alternatively, you can specify a JNDI name.
     
     Note: When you specify a JNDI name, the deployment descriptor of the Oracle Applications adapter must associate this JNDI name with configuration properties required by the adapter to access the database.
     
     The JNDI name acts as a placeholder for the connection used when your service is deployed to the BPEL server. This enables you to use different databases for development and later for production.
     
     Note: For more information about JNDI concepts, refer to Oracle Fusion Middleware User's Guide for Technology Adapters.
     
4. Click Next in the Service Connection dialog box. You can add an interface view by browsing through the list of open interface views available in Oracle Applications.
   For Oracle E-Business Suite Release 12:
   If you are connecting to Oracle E-Business Suite Release 12, then the IREP File not present dialog box appears indicating that Adapter could not find the Oracle Integration Repository data file corresponding to the database you are connecting in your workspace. Absence of the data file would make browsing or searching of Integration Repository tree considerably slow. You can choose to extract the data file and create a local copy of the Integration Repository data file. Once it is created successfully, Adapter will pick it up automatically next time and retrieve data from your local Integration Repository.
   You can select one of the following options:
   
   • Click Yes to extract the Integration Repository data file.
     Extracting Integration Repository Data File
     
     After the system successfully creates a local copy of the Integration Repository data file, next time when you connect to the database, you will find the IRep Data File field appears in the Operation dialog box indicating where your local copy exists with the creation date and time as part of the file name.
     Using the Local Integration Repository Data File
     
   • Click No to query the Integration Repository data file from the live database you are connecting to display the Integration Repository tree.
     
     Note: It is highly recommended that you create a local copy of the Integration Repository data file so that Adapter will query the data next time from the local copy in your workspace to enhance the performance.
     
   For Oracle E-Business Suite pre-Release 11.5.10:
   If you are connecting to a pre-11.5.10 Oracle Applications instance, you must select the interface type in the Adapter Configuration Wizard. Select Tables/Views/APIs/Concurrent Programs to proceed.
5. Click Get Object to open the Oracle Applications Module Browser.
   Selecting a view from the Module Browser
   
   Oracle Applications Module Browser includes the various product families that are available in Oracle Applications. For example, Applications Technology or Order Management Suite are product families in Oracle Applications. The product families contain the individual products. For example, Order Management Suite contains the Order Management product. The individual products contain the business entities associated with the product. For example, the Order Management product contains the Sales Order business entity.
   Business entities contain the various application modules that are exposed for integration. These modules are grouped according to the interface they provide. concurrent programs can be found under the Open Interfaces category.
6. Navigate to Order Management Suite (OM_PF) > Order Management (ONT) > Sales Order (ONT_SALES_ORDER) > Interface_Views to select OE_HEADER_ACKS_V.
   Click OK. The Application Interface page appears with the selected interface view.
   Adapter Configuration Wizard - Application Interface Page
   
7. Click Get Object to open the Oracle Applications Module Browser again to select another interface viewOE_LINE_ACKS_V using the same navigation path Order Management Suite (OM_PF) > Order Management (ONT) > Sales Order (ONT_SALES_ORDER) > Interface_Views.
   Click OK. The Application Interface page appears with the two selected views.
   Adapter Configuration Wizard - Application Interface Page
   
   Click OK.
8. Click Next. The Operation Type page is displayed.
   Adapter Configuration Wizard - Operation Type Page
   
   Select the Perform an Operation on a Table radio button and then choose the Select check box.
   
   Note: Interface views can be used only for Select operations.
   
9. Click Next. The Select Table page is displayed.
   Adapter Configuration Wizard - Select Table Page
   
   Select OE_HEADERS_ACKS_V as the root database table for this service's query.
10. Click Next. The Define Primary Keys page is displayed.
    Adapter Configuration Wizard - Define Primary Keys Page for OE_HEADERS_ACKS_V
    
    Select the following primary keys for the OE_HEADERS_ACKS_V table:
    
    • ORIG_SYS_DOCUMENT_REF
    • ORDER_SOURCE_ID
    Click Next.
    Select the same primary keys for the OE_LINE_ACKS_V table.
    Adapter Configuration Wizard - Define Primary Keys Page for OE_LINE_ACKS_V
    
11. Click Next. The Relationships page appears.
    Click Create to open the Create Relationship dialog.
    Defining Relationships
    
    Enter the following information to define the relationship between the header and the detail table:
    
    • Select the OE_HEADERS_ACKS_V as the parent table and OE_LINES_ACKS_V as the child table.
    • Select the mapping type: OE_HEADERS_ACKS_V has a 1:M Relationship with OE_LINES_ACKS_V
      
      Note: If foreign key constraints between tables already exist in the database, then two relationships are created automatically while importing tables. One of the relationships is 1:M relationship from the source table, which is the table containing the foreign key constraints, to the target table. The other relationship is a 1:1 back pointer from the target table to the source table.
      
    • Select the Private Owned check box.
    • Associate the foreign key fields with the primary key fields:
      
      • OE_HEADERS_ACKS_V.ORDER_SOURCE_ID: ORDER_SOURCE_ID
      • OE_HEADERS_ACKS_V.ORIG_SYS_DOCUMENT_REF: ORIG_SYS_DOCUMENT_REF
    • The Relationship Name field is populated automatically by default. You can optionally specify a new name for the relationship you are creating.
12. Click Next. The Attribute Filtering page appears. Leave default selections unchanged.
    Adapter Configuration Wizard - Attribute Filtering Page
    
    Click Next. The Define Selection Criteria page appears.
    Click Add to add a new parameter if necessary. Click Edit to use the graphical expression builder to create the expression. You can define your own custom Select SQL by modifying the predefined SQL string.
13. Click Next. The Advanced Options page appears.
    Click Next.
14. Click Finish. The wizard generates the WSDL file corresponding to the selected interface. This WSDL file is now available for the partner link.
    Click Apply and then OK. The partner link is created with the required WSDL settings.

Adding a Partner Link for File Adapter

Use this step to configure a BPEL process by adding a partner link for File Adapter. This allows the acknowledgement data to be written to an XML file.

To add a partner link for the file adapter

1. In JDeveloper BPEL Designer, click BPEL Services in the Component palette.
   Drag and drop File Adapter from the BPEL Services list into the right Partner Link swim lane of the process diagram right after the partner link you just created. The Adapter Configuration Wizard Welcome page appears.
   Click Next.
2. In the Service Name page, enter a name for the file adapter service, such as WriteAckdata.
   Specifying the Service Name
   
3. Enter a name for the file adapter service, such as WriteAckData.
4. Click Next. The Adapter Interface page appears.
   Specifying the Adapter Interface
   
   Select the Define from operation and schema (specified later) radio button and click Next.
5. In the Operation page, specify the operation type. For example, select the Write File radio button. This automatically populates the Operation Name field.
   Specifying the Operation
   
6. Click Next to access the File Configuration page.
   Configuring the Output File
   
7. For the Directory specified as field, select the Logical Name radio button. Enter outputDir as the Directory for Outgoing Files (logical name) and specify a naming convention for the output file, such as EventAck%yyMMddHHmmss%.xml.
   
   Tip: When you type a percent sign (%), you can choose from a list of date variables or a sequence number variable (SEQ) as part of the filename.
   
   Confirm the default write condition: Number of Messages Equals 1.
8. Click Next, and the Messages page appears. For the output file to be written, you must provide a schema.
9. Click Browse to access the Type Chooser.
10. Expand the node by clicking Project Schema Files > ViewAck_table.xsd and selecting OeHeaderAcksVCollection. Click OK.
    The selected schema information will be automatically populated in the URL and Schema Element fields.
    Populating the Selected Message Schema
    
11. Click Next and then Finish. The wizard generates the WSDL file corresponding to the partner link. The main Create Partner Link dialog box appears, specifying the new WSDL file.
    Completing the Partner Link Configuration
    
12. Click Apply and then OK to complete the configuration and create the partner link with the required WSDL settings for the File Adapter service.

Configuring the Invoke Activities

Based on the scenario described earlier, you need to configure the following two Invoke activities:

1. To get the purchase order acknowledgement details by invoking the ViewAck partner link.
2. To write the purchase order acknowledgement information to an XML file by invoking WriteAckdata partner link for File Adapter.

To add the first Invoke activity for a partner link to get acknowledgement details:

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette. Drag and drop the first Invoke activity into the center swim lane of the process diagram, between the receiveInput and callbackClient activities.
2. Link the Invoke activity to the ViewAck service. The Edit Invoke dialog appears.
   The value of the Operation field is automatically selected based on the associated partner link. For example, this Invoke activity is associated with an interface table partner link for 'select' operation only, the 'ViewAckSelect' service name with 'Select' operation is populated as the value.
3. Enter a name for the Invoke activity, then click the Create icon next to the Input Variable field to create a new variable. The Create Variable dialog box appears.
4. Select Global Variable, then enter a name for the variable. You can also accept the default name.
   Click OK.
   Create Variable
   
5. Click the Create icon next to the Output Variable field to create a new variable. The Create Variable dialog box appears.
6. Select Global Variable, then enter a name for the variable. You can also accept the default name.
   Click OK to close the Create Variable dialog.
   Click Apply and then OK in the Edit Invoke dialog box to finish configuring the Invoke activity.
   
   The Invoke activity appears in the process diagram.

To add the second Invoke activity for a File Adapter partner link to write acknowledgement details in an XML file:

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette. Drag and drop the first Invoke activity into the center swim lane of the process diagram, right after the first Invoke activity.
2. Link the Invoke activity to the WriteAckdata service for File Adapter. The Edit Invoke dialog appears.
3. Enter a name for the Invoke activity, then click the Create icon next to the Input Variable field to create a new variable. The Create Variable dialog appears.
4. Select Global Variable, then enter a name for the variable. You can also accept the default name. Click OK to return to the Edit Invoke dialog box.
   Click Apply and then OK to finish configuring the Invoke activity.
   
   The second Invoke activity appears in the process diagram.
   

Configuring the Assign Activity

The next task is to add an Assign activity to the process map. This is used to provide values to the input variables.

To configure the Assign activity

1. In JDeveloper BPEL Designer, select BPEL Activities and Components in the component palette.
   Drag and drop the Assign activity into the center swim lane of the process diagram between the two Invoke activities that you just created earlier.
2. Double-click the Assign activity to access the Edit Assign dialog.
   Click the General tab to enter a name for the Assign activity. For example, setAckdata.
3. Select the Copy Operation tab, click the 'Plus' sign icon and select Copy Operation from the menu. The Create Copy Operation window appears.
   Specifying a Copy Operation Action
   
4. Enter the parameter information:
   
   • In the From navigation tree, select type Variable, then navigate to Variable > Process > Variables > Invoke_1_ViewAckSelect_OutputVariaable >OeHeaderAcksVCollection and select ns3:OeHeaderAcksVCollection.
     The XPath field should contain your selected entry.
   • In the To navigation tree, select type Variable, then navigate to Variable > Process > Variables > Invoke_2_Write_InputVariable > body and select ns3:OeHeaderAcksVCollection. The XPath field should contain your selected entry.
     
   • Click OK. The Edit Assign dialog box appears.
   After assigning values to the input variables, click Apply and then OK.
   The complete BPEL process diagram should be shown:
   BPEL Process Diagram
   
   Click the composite.xml to display the Oracle JDeveloper composite diagram:
   
   Note: Click the Source tab of composite.xml to enter a value for the physical directory outputDir for the reference WriteAckdata (such as /usr/tmp).
   /usr/tmp
   Specifying the Physical Directory for the Property
   
   
   Oracle JDeveloper Composite Diagram
   

Run-Time Tasks for Views

After designing the BPEL process, the next steps are to deploy, run and monitor it.

1. Deploy the BPEL process.
2. Test the BPEL process.

Deploying the BPEL Process

You must deploy the BPEL process before you can run it. The BPEL process is first compiled, and then deployed to the application server (Oracle WebLogic Server) that you have established the connection.

Prerequisites

Before deploying the BPEL process using Oracle JDeveloper, you must ensure the following:

• You must have established the connectivity between the deign-time environment and an application server.
  For more information, see Configuring the Data Source in Oracle WebLogic Server and Creating an Application Server Connection.
• Oracle WebLogic Server has been started.
  Before deploying the BPEL process, you need to start the Oracle WebLogic Server that you have established the connection.
  If a local instance of the WebLogic Server is used, start the WebLogic Server by selecting Run > Start Server Instance from Oracle JDeveloper.
  Once the WebLogic Admin Server "DefaultServer" instance is successfully started, you should find that and DefaultServer started message in the Running:DefaultServer and Messages logs.
  
  

To deploy the BPEL process

1. Select the BPEL project in the Applications Navigator.
2. Right-click the project name, and then select Deploy > [project name] > [serverConnection] from the menu that appears.
3. The BPEL process is compiled and deployed. You can check the progress of the compilation in the Messages window.
   Messages Window
   

Testing the BPEL Process

Once the BPEL process is deployed, you can manage and monitor the process from the Oracle Enterprise Manager Fusion Middleware Control Console. You can also test the process and the integration interface by manually initiating the process.

To manually initiate and monitor the BPEL process

1. Navigate to Oracle Enterprise Manager Fusion Middleware Control Console (http://:/em). The composite you deployed is displayed in the Applications Navigation tree.
   

   

2. Enter username (such as weblogic) and password and click Login to log in to a farm.
   You may need to select an appropriate target instance farm if there are multiple target Oracle Enterprise Manager Fusion Middleware Control Console farms.
3. From the Farm base domain, expand the SOA > soa-infra to navigate through the SOA Infrastructure home page and menu to access your deployed SOA composite applications running in the SOA Infrastructure for that managed server.
   
   Note: The Farm menu always displays at the top of the navigator. As you expand the SOA folder in the navigator and click the links displayed beneath it, the SOA Infrastructure menu becomes available at the top of the page.
   
   Click the SOA composite application that you want to initiate (such as 'WriteAck') from the SOA Infrastructure.
   Click Test at the top of the page.
4. The Test Web Service page for initiating an instance appears. You can specify the XML payload data to use in the Input Arguments section.
   Enter the input string required by the process and click Test Web Service to initiate the process.
   Testing Web Service
   
   The test results appear in the Response tab upon completion.
5. Click on the BPEL process name and then click the Instances tab. The SOA composite application instance ID, name, conversation ID, most recent known state of each instance since the last data refresh of the page are displayed.
   In the Instance ID column, click a specific instance ID to show the message flow through the various service components and binding components. The Flow Trace page is displayed.
   In the Trace section, you should find the sequence of the message flow for the service binding component (writeack_client_ep), BPEL component (WriteAck), and reference binding components (ViewAck and WriteAckdata). All involved components have successfully received and processed messages.
   If any error occurred during the test, you should find it in the Faults section.
6. Click your BPEL service component instance link (such as WriteAck) to display the Instances page where you can view execution details for the BPEL activities in the Audit Trail tab.
   Click the Flow tab to check the BPEL process flow diagram. Click an activity of the process diagram to view the activity details and flow of the payload through the process.
7. Verifying Records in Oracle Applications
   Log on to Oracle Applications with Purchasing, Vision Operations (USA) responsibility and select Purchase Order from the navigation menu.
   The Oracle Applications Forms open up with the Purchase Order forms.
8. Create a purchase order with the following header values:
   
   • Supplier: Enter a supplier information, such as 'Advanced Network Devices'.
   • Site: Select a site information, such as 'SANTA CLARA-ERS'.
9. On the Lines tab, enter a data row with the following values:
   
   • Type: Goods
   • Item: CM13139
   • Quantity: 1
   • Description: Hard Drive - 8GB
   • Promised: Enter any future date in the format of dd-mmm-yyyy (such as 23-JUN-2009)
10. Save your purchase order. The status of the purchase order is 'Incomplete'.
11. Click Approve. The Approve Document form appears.
    Click OK to confirm the approval.
    
    Note: Because the trading partner is set up and valid, the transmission method is automatically set to XML.
    
    

    

    Add caption

    The status of the purchase order is now changed to 'Approved'. For future reference, note the value of the PO, Rev field. For example, the PO number 5789.
    Once the purchase order is approved, the order details should be recorded in the system.
    After deploying the BEPL process, the order acknowledgement information should be retrieved from the OE_HEADER_ACKS_V and OE_LINE_ACKS_V interface views.