How Can I Get an Instance ID for Oracle ESB?

A new XPath function was added in 10.1.3.3 to get instance IDs. This section provides an example in which you invoke a BPEL process from an ESB process and pass the ESB instance ID to the BPEL process, along with other data. 1. Define a simple ESB project: RS > Synch Routing Rule > File Adapter. 2. Perform a transformation in the routing service The only unmapped element in the target XML file is the InstanceId field element. 3. Perform the following steps to get the instance ID: a. Go to Design View. b. Select Advanced Functions in the Component Palette. c. Select xpath-expression and drag it to the middle column. d. Double-click the function icon. e. Enter ehdr:getInstanceID() in the XPath Expression field. f. Click OK. 4. Click Yes when prompted with a warning. 5. Map the function to the InstanceID element and save the project. 6. Return to the routing service where the XSL transformation activity is defined. 7. Double-click the routing service. 8. Expand the Properties section and add the following property: EnableAccessBusinessEvent=true 9. Save and deploy the project. The instance ID function should now work.

ESB, BPEL using Oracle SOA Suite: Article

Getting Comfortable with Oracle SOA Suite Getting Comfortable with Oracle SOA Suite Before starting this white paper let me tell you that I am also like you (readers) who are from the world of Oracle, PLSQL, Oracle E-Business Suite work areas who is trying to get comfortable with the upcoming technologies related to Service Oriented Architecture. I am not an expert in SOA arena. I am going to try to put things in simple terms. Some of you will differ with my opinion of starting developments related to ESB/BPEL without fully understanding the concept but I think this can also be one way of getting to the debth of the subject by actually developing it. For Oracle Apps folks I would suggest, just start thinking about Oracle Workflow. All things which you can do using workflow can be done using BPEL and interfaces using (FTP/Shell Script/PLSQL) can be built using ESB. I will be using Oracle SOA Suite 10.3.1.1 and Oracle JDeveloper 10.3.3.3 software for demos/screen shots. Defining Acronym Jargons in SOA world When we enter the world of Service Oriented Architecture we come across various acronyms viz. XML, SOA, ESB, BPEL, WSDL, XSLT, SOAP, XSD, DTD etc. Let’s define each of them. XML is the eXtensible Markup Language accepted by the industry as ideal vehicle for sharing structured data among applications and organizations. XML is becoming universally understood, many applications provide inputs and outputs in XML. XML makes data self describing. XML eliminates fixed formats. XSD (XML Schema Definition), a Recommendation of the World Wide Web Consortium (W3C), specifies how to formally describe the elements in an Extensible Markup Language (XML) document. DTD is Document Type Definition which is again one of the industry accepted way of defining XML structure. WSDL (Web Service Definition Language) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). SOAP (Simple Object Access Protocol) a message-based protocol based on XML for accessing services on the Web. SOA A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. ESB is an open standards-based distributed synchronous or asynchronous messaging middleware that provides secure interoperability between enterprise applications via XML, Web services interfaces and standardized rules-based routing of documents. BPEL (Business Process Execution Language) for Web services is an XML-based language designed to enable task-sharing for a distributed computing or grid computing environment - even across multiple organizations - using a combination of Web services. Installing Oracle SOA Suite Download SOA Suite installable soa_windows_x86_101310_disk1.zip from oracle.com. Unzip the file in C:\OracleSOAInstall and run setup.exe. During installation you will get two options viz. Basic Install and Advanced Installation. Generally SOA Suite needs a database for installation. If Basic installation is selected then it automatically installs Oracle Database Lite on the machine while Advanced Installation needs Oracle Database 10G (10.2.0.3 or higher). For advanced installation, oracle database needs to have following schemas ORAESB, ORABPEL and ORAWSM. Basic installation installs following components · Oracle Containers for J2EE · Oracle SOA Suite including Oracle BPEL Process Manager, Oracle Enterprise Service Bus (ESB), Oracle Web Services Manager (OWSM), and Oracle Business Rules. · Oracle Enterprise Manager 10g Application Server Control · Oracle Process Manager and Notification Server · OC4J Java Single Sign-On Advanced installation includes all the above components along with Oracle HTTP Server with SSL Support. I would suggest not going for advanced installation if you are installing Windows XP Professional desktop/laptop because I always found issues Oracle Web Services Manager and Oracle BPEL manager during advanced installation. Using Basic installation as well at the Oracle BPEL Process Manager fails to configure at the end of installation but without exiting installation screen you can restart SOA Suite using windows start menu and retry BPEL process manager configuration. During installation please make a note of Application Server Instance Name (e.g. SOA_AS) and administrator username oc4jadmin and password. This will be needed all the time for login on to Application Server Console, BPEL Console, ESB Console and WSM Console. After Basic installation, application server is accessible at URL http://localhost:8888 or http://<machine>:<port> where you will find all the links to BPEL Process Manager, Web Services Manager Console and ESB Console. Application Service Control Click on Application Server Control, enter username (oc4jadmin) and password and make sure all services are running. If any of the service status is down then you can start the service by clicking start button. Click on HomeàApplications to which displays list of all applications. Click on Web Services Link to display all deployed web services Configuring the Container Once you install Oracle SOA Suite, you need to create a connection pool, data source, and database adapter, Oracle Applications Adaptor Point your browser to the Enterprise Manager for your installation of Oracle SOA Suite using URL http://<machine>:<port> e.g. http://localhost:8888 From the right-hand side Manage Your SOA Suite portlet, click the Application Server Control link. The Application Server Control Console displays the administrator logon dialog box. Enter oc4jadmin as username and its password Connection Pool and Data Source Create a connection pool and JDBC data source for the OC4J instance. Data source is used to get a connection to a database server. You must define one connection pool and its connection factory. Select the home OC4J link, which takes you to OC4J home page Click on Administration Link In Services > JDBC Resources, click the Go To Task icon to navigate to JDBC Resources page In the Connection Pools section, click the Create button to navigate to connection pool navigation page Accept defaults, and click Continue. Enter the connection pool name, Database SID, User Name password etc. Test the connection. If connection is successful then click finish Under Data Sources, click Create (Similar to Step c) and navigate to Create Data Sources screen. Accept default and click continue Enter values for Data Source Name and JNDI Location (Please note this JNDI name should be used same as JDNI Name while using DB adaptor in Oracle JDeveloper) Click Finish to complete Creation of data source Create a similar Data Source using APPS username for connecting to Oracle E-Business Suite Database. This data source will be used for creating Database Adaptor and Apps Adaptor Adaptors in SOA Suite In SOA world, systems talk to each other through various adaptors. In the context of an SOA an adapter is an intermediary service that bridges incompatible data formats between services and its clients. An adapter often also acts as a façade or technology gateway. Oracle SOA suite is shipped with various such adaptors given in following screenshot In this article we will take a look at how to setup DbAdaptor, AppsAdaptor, File Adaptor and FTP Adaptor Database Adaptor In Application Server Console, click on OC4J: home-->Applications Click on Default Application to arrive at screen displayed above Click DbAdaptor link and then click connection factories link Click Create Button to create connection factory. Click Continue Specify Connection Factory JNDI Name and most important xADataSourceName same as Data Source JNDI Name created few steps before i.e. eis/DB/APPS_SOADB Oracle Applications Adaptor In Application Server Console, click on OC4J: home-->Applications Click on Default Application to arrive at screen displayed above Click AppsAdaptor link and then click connection factories link Click Create Button to create connection factory. Click Continue Specify Connection Factory JNDI Name and most important xADataSourceName same as Data Source JNDI Name created few steps before i.e eis/DB/APPS_SOADB File Adaptor File adaptors is already setup with default installation and can be used as it is while developing ESB or BPEL applications. For File Adaptor the JNDI location is eis/FileAdapter which can be used for writing files at any location on machine hosting Oracle SOA Suite FTP Adaptor FTP Adaptors can be created for each destination machine by setting up configuration properties needed for FTP process. Conclusion This much knowledge of configuring Oracle SOA Suite is sufficient to start developing applications based on ESB and BPEL. In the next article we will take an overview of Oracle JDeveloper 10.1.3.0 and various services, Process Activities involved in developing ESB and BPEL projects.

Invoking EJB's from Oracle ESB using WSIF

A common requirement with the Oracle ESB is to use it to invoke one or more EJBs; one way to do this is to create a standard SOAP service from an existing EJB using the wizards in JDeveloper. Whilst this is straight forward, it has the disadvantage that you introduce the overhead of using SOAP/HTTP as well as losing the ability to invoke the EJB as part of a wider transaction. An alternative approach to SOAP, is to use WSIF (Web Services Invocation Framework) which allows us to expose the EJB through a standard WSDL interface but bind to it a run time using native bindings (i.e. RMI) as opposed to SOAP. This provides us with significantly improved performance and enables us to include the invocation of the EJB within a distributed transaction. This document covers how to go invoke an EJB 3.0 from the ESB via WSIF. For the purpose of this document, we will create a simple EJB (Greeting) with a single method helloWorld. However to make this example a bit more a bit more realistic, we will pass in a complex type Person, which has the properties title, firstName and lastName. Note: For the sake of this example, we have assumed you have created an application with JDeveloper containing a single project called Greeting. Creating the WSIF WSDL File Before you can invoke an EJB via WSIF you need to create a WSDL file which contains the appropriate binding information required by the WSIF framework to invoke the EJB. There are two basic approaches you can take: Contract First – With this approach we start with by defining an abstract WSDL document which defines the service and its corresponding operations and then write an EJB which implements this contract. This EJB will typically act as a wrapper to one or more existing EJBs. EJB First – Here we start with one or more EJB and create a WSDL interface based on the EJB and it’s operations, and then the ESB or BPEL to assemble these operations into a meaningful service. For the sake of this article we are going to take the contract first approach as this is generally accepted as best practice. In order to do this we will need to carry out the following steps: Define the abstract WSDL for the required service Implement and deploy the corresponding EJB Add the WSIF bindings for the EJB to our abstract WSDL. Implement and Deploy an ESB project to invoke the EJB We cover each of these steps in detail below. Define Abstract WSDL File The first step is to define a simple abstract WSDL file to describe your services, for our purpose we have defined the following: At first glance there is nothing here to indicate that the WSDL is for a service to be implemented using an EJB. The only thing worth mentioning is that we have defined our XML schema elements for our input and outputs parameters in a separate file, which we have imported into our WSDL document. The reason for doing this it that at a later stage we will need to generate Java classes based on the XML Schema, and separating out the schema makes this process slightly simpler, especially if you need share the Schema between multiple EJBs. The schema for Person.xsd is as follow: Note: We have defined all our parameters as elements and NOT complexTypes since the Oracle ESB will complain if you try and use a WSDL which uses complexTypes in its message definitions. Implement Session EJB The next step is to implement a corresponding stateless session EJB to implement our Greeting service. The simplest way to do this in JDeveloper is right click your Greeting project and select New. This will bring up the ‘Gallery’ as shown below. Browse to the Business Tier-> EJB section and select Session Bean (as shown below) and click OK. Figure 1 - Creating a Session Bean This will launch the Create Session Bean Wizard. In Step 1, select ‘Enterprise Java Beans 3.0(J2EE 5.0)’ as the version of EJB you wish to use and click next. In step 2; specify the EJB Name, i.e. Greeting, Keep the default settings for the Session EJB 3.0 options (as shown below) and click ‘Next’. Figure 2 – Specify EJB Name and Options Next specify the bean class name. This will have already been defaulted based on the EJB Name you specified in the previous step (i.e. it will have appended bean to it). Leave the class name as is, but specify the package name as appropriate. In our case we set the package name to com.bpelpeople.ejb and then click next. Figure 3 – Specify Class Name Finally specify that you want the EJB to implement a remote, local and web service endpoint interface (as shown below). Then hit ‘Finish’ to generate your EJB. Figure 4 – Specify EJB Interfaces For each operation defined in our WSDL file we should create the equivalent method in our EJB. For each method we need to define its input and return parameters. For operations or method that return simple XML types (e.g. xsd:string, xsd:integer) we can use the equivalent type in Java. However for complex types, such as our Person element we need to implement the appropriate classes required for serialization/de-serialization between java and xml. Using schemac to generate serialization/de-serialization classes As part of the SOA Suite, Oracle provides the schemac utility (bundled with BPEL PM) which you can use to generate the serialization/de-serialization classes. To use this utility open the BPEL Developer Prompt and then run the following command: schemac –noCompile –sourceOut < dir=""> < file=""> This will generate the source Java for serialization/de-serialization classes for the specified schema file (e.g. Person.xsd in our case) and places these within the specified source directory. Within JDeveloper you will need to import these classes into you project containing your EJB. You will notice that for each element, schemac will generate three classes (e.g. Person, IPerson and PersonFactory); we will use the actual concrete class (i.e. Person) for the input parameter to our method. So for our Greeting EJB we have defined the following method: Setting Project Classpath Once you have imported the generated Java classes into your project, in order to compile them you will need to add the orabpel.jar file to your project classpath, this is located at: $SOA_HOME/bpel/lib/orabpel.jar Create Deployment Descriptor Finally we need to create a deployment descriptor for our EJB, within the Application Navigator right click on our Greeting project and select ‘New’. From the gallery, browse to General -> Deployment Profiles and select ‘EJB Jar File’. This will bring up the Create Deployment Profile window. Figure 7 – Specify Deployment Profile Name Specify a profile name, i.e. ‘Greeting’ in our example and click ‘OK’. This will launch the ‘EJB JAR Deployment Profile Properties’ window, as shown below. Figure 8 – EJB JAR Deployment Profile Properties Specify a name for the application, in our case we have chosen ‘GreetingApp’ (note: you will need to make a note of this value as you will use it when defining the WSIF Binding for your service) and click ‘OK’. Note: you will need to define an Application Server connection to the OC4J instance to which you want to deploy your EJB first. Deploying the EJB You can now use JDeveloper to deploy your EJB, however before doing this you should define an Application Server connection with JDeveloper to the oc4j instance on which the SOA Suite is deployed (e.g. oc4j_soa). You are now ready to deploy your EJB. You can now use the deployment file you just created to deploy your EJB. Right click on this file and select deployTo-> oc4j_soa (where oc4j_soa is the name of your application server connction). As part of the deployment process, JDeveloper will bring up the Configure Application window. However if you click ‘OK’ and follow the standard deployment process, you will need to include the orabpel.jar within your .ear file. This can be a bit cumbersome, particularly if you have several EAR files to deploy. The other option is to deploy your application as a child of the orabpel application. By designating orabpel as the parent application, your EJB will inherit the set of shared libraries imported by the parent including orabpel.jar. To do this select ‘GreetinApp’ within the ‘Configure Application’ window and then select orabpel as the parentApp as show below in figure 9. Figure 9 – Setting the Parent Application Then click ‘ok’ and JDeveloper will complete the deployment of our EJB. Adding WSIF Bindings Now that we have written and deployed our EJB we are ready to add the WSIF bindings to our abstract WSDL file to enable it to be called from the ESB. Modify Definitions Element Within the <definitions> element of your WSDL file you need to add the following namespaces: xmlns:ejb=”http://schemas.xmlsoap.org/wsdl/ejb/” xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/" The ejb namespace allows the binding of WSDL operations to methods on an EJB class. The format namespace adds support for mapping Java types to XML Schema definitions. Add Bindings Element This is where we bind our service to an EJB rather than a standard SOAP service. For our example, the WSDL <binding> element is defined as follows: Ejb Binding <ejb:binding> should be the first element within our <bindings> tag and identifies that this is service is bound to an EJB rather than a SOAP service. Type Definitions Next, you need to map the XML Schema elements used within the WSLD message definitions to the Java types used in the method invocations for your EJB. The <format:typemapping> element will contain one <format:typemap> for each xml schema element that we need to map, it has two attributes encoding and style both of which should be set to ‘Java’ to indicate that we are mapping to Java classes. The <format:typemap> element has two attributes, typeName which hold the name of the xml schema element that we are mapping and formatType which contains the class name of the Java class to which we are mapping it. In our example, we have specified two type mappings one between our Person element and the corresponding class that we generated using schemac, and the other between the Return element and the java.lang.String class. Method Mapping The final step is now to map the EJB method calls onto the WSDL operations. This is done using the <ejb:operation> tag to identify which EJB method should be used to support a given operation This element has the following attributes: methodName – which should be set to the equivalent method within the EJB. interface – which should be set to ‘remote’. parameterOrder – which should be set to name of the <part> contained with the input message for the operation. returnPart – which should be set to the name of the <part> contained with the output message for the operation. Add Services Binding Finally we have to add the element to our WSDL to specify where to locate the service. This looks pretty normal, except that instead of a <soap:address> element, we need to specify an <ejb:address> element. This contains one attribute jndiName; which specifiec the JNDI Name of the deployed EJB. In our example the <service> element is defined as follows: Calling your EJB from ESB We are now ready to invoke our EJB from within our ESB. To do this, create a SOAP Service based on our WSDL file within your ESB project in the normal way (note you will need to import the Schema into your ESB project first). However before registering your ESB project you will need to define the following endpoint properties on your service: java.naming.factory.initial - This is used to specify the initial context factory and should be set to com.evermind.server.rmi.RMI InitialContextFactory. java.naming.provider.url - Used to specify the URL for the EJB provider, the structure of this is covered below. java.naming.security.principal - Specifies the user id to be used to invoke the EJB and should be set to the appropriate value (e.g. oc4jadmin) java.naming.security.credentials - Specifies the corresponding password to be used to invoke the EJB and should be set to the appropriate value (e.g. welcome1). This is so that the ESB is able to locate and invoke the EJB at run time. java.naming.provider.url Specifies the URL for the provider (or application) which contains our EJB, this takes the form: opmn:ormi://<hostname>:<opmn request port>:<oc4j container>/<application> Where <hostname> is the host on which the Oracle Application Server is deployed. <opmn request port> is the runtime port for OPMN requests on the Oracle Application Server (e.g. 6003). <oc4j container> is OC4J container to which we have deployed our EJB Application (e.g. oc4j_soa). <application> is the name of the application in which our EJB is deployed, we specified this as part of our deployment descriptor (i.e. GreetingApp). Unfortunately JDeveloper won’t allow you to specify these specific properties, so you will need to enter the .esbsvc file outside of JDeveloper. To do this first close down JDeveloper (otherwise you can get sync issues) and then open the appropriate .esbsvc file in your favourite text editor and specify the endpoint properties at the end of this file as follows: Once done, you can open up JDeveloper and deploy your ESB project. Deploy EJB Classes to ESB Engine Before we can call the EJB from the ESB, we must first deploy the remote interface class of our EJB (Greeting.class) and our Java serialization/de-serialization classes to the ESB engine, the simplest way to do this is to copy the java classes into the directory: <soa_home>\bpel\system\classes Once done you will need to re-start the SOA Suite so that it picks up the classes. Deploy Patch to ESB Finally if you are using 10.l.3.3 of Oracle SOA Suite you will need to install patch 6314009 which is available at metalink.oracle.com.

Oracle BPEL and ESB

Hi, The goal of the blog is to spread my personal view and knowledge about the Oracle product named Oracle BPEL Process Manager. As I can see the many customers are moving to a Service Oriented Architecture (SOA), the BPEL product of Oracle is often a good fit. The upcoming release with Enterprise Service Bus (ESB), the product will be named Oracle SOA Suite and will cover the complete SOA functionality that customers are expecting. Currently Oracle does not have a real ESB product. Oracle Interconnect can act as an ESB, but is not integrated with Oracle BPEL PM. Regards, Manish