JmsAdapter Usage in Oracle SOA 11g BPEL

The JMS architecture uses one client interface to many messaging servers. The JMS model has two messaging domains, point-to-point and publish-subscribe. In the point-to-point domain, messages are exchanged through a queue and each message is delivered to only one receiver. In the publish-subscribe model, messages are sent to a topic and can be read by many subscribed clients.

There 3 steps to do in order to successfully use JmsAdapter to access the JMS destination in Oracle Bpel.

• Add JmsAdapter into your Bpel in JDeveloper. Adding it is actually following the steps of Adapter Configuration Wizard.

Wizard Step 2: Give the service name to JMS Adapter.

Wizard Step 3: Select Oracle Weblogc JMS as JMS provider.

Wizard Step 4: Specify the application server for connection.

Wizard Step 5: Select to define from operation and schema as the adapter interface.

Wizard Step 6: This adapter is used to produce message.

Wizard Step 7: Specify the JMS destination and JNDI name for the connection factory.

Please note here: Destination name is the JNDI name for the destination used in normal JEE JMS resource.

And connection factory is the JNDI name used in JMS Adapter rather than JNDI in normal JEE JMS resource.

Wizard Step 8: Specify the schema for the payload of the JMS message.

After all wizard steps are finished, one .jca file is created where the connection factory and destination are specified.

• Configure deployed JmsAdapter from Console to add outbound connection.

Click on Your domain/Deployments in Console and then select JmsAdapter.

Click on Configuration tab and then click on Outbound Connection Pools and then expand the group oracle.tip.adapters.jms.IJmsConnectionFactory.

Click the New button and select oracle.tip.adapters.jms.IJmsConnectionFactory.

Click on Next button and type in JNDI name for Outbound Connection Instance.

Please note here: This JNDI name should be the same as you specify in Wizard Step 7 when configuring Adapter in JDeveloper and then click on Finish button.

Modify the property of ConnectionFactoryLocation of this new created Outbound Connection.

Select your domain/Deployments/JmsAdaoter and then select Configuration tab and then expand oracle.tip.adpater.jms.IJmsConnectionFactory. Click on the new created Outbound connection: eis/wls/InventoryQueueConnectionFactory and then click on

Then type in the JNDI name of JMS connection factory as the value to the property: ConnectionFactoryLocation.

• Configure physical JMS destination and connection factory in Oracle Weblogic Enterprise Manager.

Click on your domain/Services/Messaging/JMS Modules

Select KMS Module: SOAJMSModule.

Click on New Button to create the JMS destination.

Select the type of resource to be created as Queue and then click on Next button.

Type in the name of the physical queue and JNDI name for this queue and then click on Finish button.

Repeat the creation process to create the JMS connection factory.

Click on New button.

Select the type of resource to be created as Connection Factory and then click on Next button.

Type in the name for the queue connection factory and JNDI name for this connection factory.

Please note: This JNDI name should be the same as the value of the property

Finally click on Finish button.

• Test the JMS message is sent to the queue.

After successfully running your BPEL one message should be sent to the queue. It can be verified using Console.

Click on your domain/Services/JMS Modules in Console and then click on SOAJMSModule.

Find your queue destination and click on it and then click on Monitoring tab.

And you will find there is one message in the queue destination. Select this queue and click on Show Messages to see the content of the message payload.

Click on the message ID and the content of the message is displayed.

Exposing E-Business Suite services using the Integrated SOA Gateway

Oracle E-Business Suite Release 12 introduced a new “Integrated SOA Gateway” that makes it very easy to expose functionality from E-Business Suite as web services.  This allows much easier integration to and from E-Business Suite.

In this post, we look at how to expose a piece of functionality in E-Business Suite as a service.  Here we are using Oracle E-Business Suite 12.1.2, a “Vision” system.

First we log on to E-Business Suite as the SYSADMIN user.

Next we navigate to the Integrated SOA Gateway responsibility and into theIntegration Repository, as shown in the image below.

For this example, we will use the Price Request.  This is found under Order Management Suite then Advanced Pricing and Price List as you can see highlighted on the left hand side of the image below.  Then select Price Request from the list of integration points.  You will see a screen like the one below, that provides details of this integration point.  You can see that in this case, it is a PL/SQL API.  On the top right of this screen, there is a new button called Generate WSDL that we can use to easily expose this PL/SQL API (or any other integration point) as a web service.  Click on that now.

After two or three seconds you should get a confirmation message, like the one below, to let you know this was completed successfully.  Next we need to enable this new service.  This is done by clicking on the Deploy button which is highlighted in the image below.

Again, after a few seconds, your screen should update to look like the one below.  You can now see a link to the service description (WSDL) that can be used to call this service from other applications, systems, etc.

You can click on that View WSDL link to see the WSDL code.  Below is the first part of the WSDL for the above example.

Note: Make sure you open the WSDL in a new window or tab, we are not finished with this page yet!  You can do this by right clicking on the link and selecting Open in new tab or similar from the popup menu (this varies from browser to browser).

The final step is to grant access to the service, so that we will be able to invoke it.  To do this, we expand the list of operations in the last part of the interface page in Integration Repository , then check the box next to the interface we want to grant access to, and click on the Grant Access button.

Now enter the username for the user you want to grant access to, or use the search button to find the user.  In this example, it will be sufficient to grant access to ASADMIN.

Then save your changes.  Your screen should now look like this:

SOA Redefined : JmsAdapter Usage in Oracle SOA 11g BPEL

SOA Redefined : JmsAdapter Usage in Oracle SOA 11g BPEL

Weblogic Authentication Provider

In WebLogic Server, Authentication providers are used to prove the identity of users or system processes. Authentication providers also remember, transport, and make that identity information available to various components of a system (via subjects) when needed. During the authentication process, a Principal Validation provider provides additional security protections for the principals (users and groups) contained within the subject by signing and verifying the authenticity of those principals.

WebLogic supports Authentication Providers that can validate user credentials based on a username-password combination or a digital certificate. The security provider repository, which stores the user and group information, can be implemented in the following ways:

• As an embedded LDAP server, which is the default used by WebLogic's security providers
• As an external LDAP store, such as Open LDAP, Active Directory, Novell, or NDS
• As a DBMS, which can be used to host the data for enterprise applications
• As a text file, which is used by WebLogic's sample security providers

Users and Groups, Principals and Subjects

A user is similar to an operating system user in that it represents a person.

A group is a category of users, classified by common traits such as job title. Categorizing users into groups makes it easier to control the access permissions for large numbers of users.

Both users and groups can be used as principals by application servers like WebLogic Server. A principal is an identity assigned to a user or group as a result of authentication.

The Java Authentication and Authorization Service (JAAS) requires that subjects be used as containers for authentication information, including principals. Each principal stored in the same subject represents a separate aspect of the same user's identity, much like cards in a person's wallet. (For example, an ATM card identifies someone to their bank, while a membership card identifies them to a professional organization to which they belong.)

The figure 1-1 below illustrates the relationships among users, groups, principals, and subjects.

As part of a successful authentication, principals are signed and stored in a subject for future use. A Principal Validation provider signs principals, and an Authentication provider's LoginModule actually stores the principals in the subject. Later, when a caller attempts to access a principal stored within a subject, a Principal Validation provider verifies that the principal has not been altered since it was signed, and the principal is returned to the caller (assuming all other security conditions are met).

The Authentication Process:

The Figure 1-2 below shows a behind-the-scenes look of the authentication process for a fat-client login. JAAS runs on the server to perform the login. Even in the case of a thin-client login (that is, a browser client) JAAS is still run on the server.

When a user attempts to log into a system using a username/password combination, WebLogic Server establishes trust by validating that user's username and password, and returns a subject that is populated with principals per JAAS requirements.

The Authentication Provider adheres to the standard JAAS framework by structuring the authentication sequence on top of a number of configurable JAAS LoginModules. LoginModules are critical components of an Authentication Provider, as they are responsible for authenticating users within a security realm and populating the subject with the required principals (existing users and groups).

WebLogic demands that you have at least one authentication provider configured in your security realm.

   Authentication Providers’ Control Flag Values :

The control flag of each authentication provider can take the following values:

REQUIRED: This option is the default setting for any Authentication Provider. A required Authentication Provider is always invoked, irrespective of the control flag settings on other providers. The overall authentication cannot succeed if any REQUIRED provider fails. Thus, REQUIRED providers are always invoked, and overall authentication fails if any one of them fails.

REQUISITE: This option also requires the Authentication Provider to succeed during the login sequence. However, all of the REQUISITE providers need not be invoked for the overall authentication to succeed. If a REQUISITE provider succeeds, the authentication proceeds as normal to other providers in the sequence. However, if it fails, the overall authentication cannot succeed, and control is immediately passed back to the application once all REQUIRED providers in the login sequence have been invoked.

SUFFICIENT: This option does not require the Authentication Provider to succeed during the login sequence. If a SUFFICIENT provider does succeed, the overall authentication proceeds to ensure that only the remaining REQUIRED providers in the login sequence are executed. However, if it fails, the overall authentication proceeds as normal to the other providers in the login sequence.

OPTIONAL: This option does not require the Authentication Provider to succeed during the login sequence. Regardless of whether an OPTIONAL provider succeeds, the authentication proceeds to other providers that have been configured as part of the login sequence.

When multiple LoginModules are used to authenticate a user, the authentication occurs in two phases. During the first phase, the modules are asked to attempt to authenticate the user. Only if the modules pass this phase is the second phase invoked. During thesecond phase, each module commits the login and assigns the relevant principals to the subject. The control flags influence how this two-phase commit occurs. Thus, for the overall authentication to succeed, the following rules must be met:

• All REQUIRED modules must be invoked, and each must successfully validate the user.
• Any REQUISITE module that gets invoked must successfully validate the user.
• If a SUFFICIENT module successfully validates the user, the overall success depends on the success of all REQUIRED modules, and any REQUISITE modules invoked before the SUFFICIENT module.
• If the login sequence consists only of OPTIONAL modules, at least one module must successfully validate the user.