Learner Series: Dynamically load XSL templates

I received a few requests from readers on how to dynamically load XSLT stylesheets in SOA 11g/12c.

This usecase finds importance when you have the following;

• You have one input source (master data) and multiple destinations each of which receives the same data in different formats
• Your destination requires minor changes on the data being sent and you don't want to redeploy the whole process causing downtime to other systems
• You have dynamic partnerlinks to connect to multiple targets each of those targets expect data in a certain format

We will leverage SOA-MDS to store and retrieve our XSL stylesheets dynamically at runtime.

Step 1: Develop your XSLT mappings and test them before you persist them on MDS
Ref: learn how to use MDS in 11g/12c

Once you have your stylesheets in MDS, you can reference them from within your BPEL process using the oramds:/ protocol

Step 2: You don't need to use the "Transform" activity in your BPEL. Use either of the following BPEL XPath Extension Functions to load and process your XSL stylesheets within your "Assign" activity.

ora:processXSLT()
ora:doXSLTransformForDoc()

For example, ora:processXSLT('oramds:/apps/stylesheets/xformOrder.xsl', $inputVariable.payload)

You can further parameterize this expression by using a DVM to store the XSL references and use dvm:lookup to get the first parameter - XML template location.

Learner Series: SOA 12c Share Resources easily using MDS

SOA 12c has simplified the way developers leverage the MDS capabilities.

Developers still have the 11g way of deploying "SOA Bundle" archives to MDS described here.
But if you are on SOA 12c, you get a simpler option.

Once you install SOA 12c quickstart, you get a file-based SOA DesignTime MDS Repository by default. You can choose where to host your MDS root.

Under the Resources window in JDeveloper, expand SOA-MDS IDE connection. You must have a default SOA_DesignTimeRepository. Go to properties and set your MDS root folder.

You can copy your resources that you want to reuse/share to your MDS root folder and reference them within your SOA composite by using the oramds:/ protocol. eg., oramds:/apps/xsd/employee.xsd

Now to create a runtime MDS repository, first create a DB MDS connection to your SOA instance using your prefix_MDS schema [prefix is what you specified during RCU config].

From the Resources window -> IDE connection panel, right click SOA-MDS and create a new SOA-MDS connection. Provide a unique connection name, choose Connection type as "DB Based MDS", select the MDS connection created above and choose the "soa-infra" partition.

Note: SOA quickstart by default uses Java derby database (no DB MDS capabilities). You must either have a compact domain installation or a full-fledged SOA installation (your staging / test / production server).

To deploy the design time MDS (file-based) resources to DB based runtime MDS repository, right click on the design time repository and choose Transfer. The wizard will prompt you for the runtime MDS to which the resources must be transferred to. Choose the resources you need to transfer and your DB MDS connection and click on Transfer.

SOA 12c Compact Domain DB Based MDS

With the release of SOA 12c, developers can now have full-fledged SOA 12c running on their desktops/laptops on the integrated WebLogic server. This is a great news for development community - as one can download the SOA/BPM 12c quickstart which comes pre-configured with JDeveloper and integrated WLS running SOA/BPM.

Some developer productivity benefits include;
1) You don't need a license for quickstart installs (for development & evaluation purposes)
2) Single jar that will install & configure WebLogic domain, SOA, JDev and everything you need to get going

However, there are some limitations with the default quickstart install. For one, the quickstart installation runs on top of Java Derby DB; and the SOA MDS is a file-based repository by default. Although for normal development purposes this may not be a big challenge, it could be an issue if you want to leverage some features such as;

1) Run-time modification of business rules
2) B2B, MFT & ESS
3) SOA Composer
4) BAM
5) BPM Composer etc.. which require a Oracle database to run.

However, there are other ways to configure your development environment to run on top of Oracle database - therefore you can have a DB based SOA MDS.

In this post, I will illustrate how to install and configure a SOA 12c compact domain for development purposes.

Pre-Requisites:

1) Download Java 7. According to the certification matrix jdk 1.7.0u55+ is supported - here
2) Download Oracle XE 11g Database - here
3) Download SOA 12.1.3 quickstart distribution - here
4) Optional components such as B2B, MFT, can be downloaded if required
Download MFT - here
Download B2B - here

Install java 7 on your environment. Note: By default on windows jdk will choose a location under "Program Files". In certain cases, I have seen the space in folder location cause unknown issues. Ensure java is installed on a location without space in the folder name eg., C:\Java

SOA 12c Quickstart Installation:

Unzip the fmw_12.1.3.0.0_soaqs_Disk1_1of1.zip

Open terminal (command prompt) as administrator
Ensure JAVA_HOME and PATH environment variables are set and points to the jdk installed
set JAVA_HOME=C:\Java\jdk1.7.0_71
set PATH=%PATH%;C:\Java\jdk1.7.0_71\bin

Step 1:
Execute the following command to install the SOA 12c quickstart
java -D64 -jar fmw_12.1.3.0.0_soa_quickstart.jar

Step 2: Provide a oracle home where SOA 12c must be installed

Step 3: Ensure the validations are okay

Step 4: Review the installation summary - provides the list of features/components installed as part of the quickstart distribution

Step 5: Review the installation progress

Step 6: Once the installation succeeds, click Finish.

At this stage, quickstart can be used if you are not looking for features such as mentioned above. Just open the JDeveloper, right click on the IntegratedWeblogicServer to create and start domain. JDeveloper takes care of creating a WLS domain and configuring it automatically.

Follow through for a compact domain installation.

If you need additional components such as B2B, BPM or MFT now is the time to install them. Let's install B2B.

Installing Oracle B2B:

Step 1:
Unzip fmw_12.1.3.0.0_b2b_Disk1_1of1.zip and execute the following command to install B2B
java -D64 -jar fmw_12.1.3.0.0_b2bhealthcare.jar

Step 2: Choose the same Oracle home that was used to install the SOA 12c quickstart

Step 3: Choose B2B or Healthcare profiles depending on requirement. Let's choose B2B

Step 4: Follow the instructions and click Finish to close the B2B installation wizard

 

I haven't detailed the MFT installation. However, should you need, it is a very straightforward installation.

Installing XE 11g Database:

Unzip the OracleXE112_Win64.zip and follow the instructions to install XE database.

Step 1: Execute setup.exe

 Step 2: Accept the license agreement

Step 3: Choose the destination folder where XE must be installed

Step 4: Enter the SYS password

Step 5: Review and click Install

Step 6: Click Finish to finish the database installation

Creating RCU schemas for compact domain:

Step 1: Execute rcu.bat from the following location - $ORACLE_HOME\oracle_common\bin

Step 2: Leave the default selection on Create Repository and click Next

Step 3: Provide the database connect information and click next

Step 4: Ignore the warning. XE is not a "certified" database but will work fine in development environments.

Step 5: Default prefix is DEV. You can change this if you need. Select the SOA Infrastructure schema from the list which will select the required schemas

Step 6: Provide a password that will be used for all the RCU schemas

Step 7: Here you can select the size for the database profile. Default is small and should be fine for development environments. Optionally you can choose to enable/disable healthcare integration

Step 8: Follow the instructions and proceed with creation of database schemas for our compact FMW domain. Click close in the final summary screen.

Create and Configure Compact SOA Domain:

In this section let's create and configure a compact SOA domain.

To enable compact domain option, set the following environment variable before executing the config.cmd script

> set CONFIG_JVM_ARGS=-Dcom.oracle.cie.config.showProfile=true

> cd $ORACLE_HOME\oracle_common\common\bin

> config.cmd

Step 1: Choose the "Create a new compact domain" option and provide a domain name/location

Step 2: This is an important step where you must choose the templates with which the compact domain will be created. Choose all the required components. Note that the templates would show up based on the installations in the current domain.

Step 3: Choose a folder location where applications would reside

Step 4: Provide a administrator username and password.

Step 5: Choose Development mode / Production Mode (basically if you choose production mode, you will be prompted for the administrator username and password every time you start the weblogic server). Choose the JDK that we installed earlier which will be picked up by default.

Step 6:Provide the database details and click Get RCU Configuration. Once you get a success message proceed to next step.

Step 7: In the JDBC component schema page, select all the schema components and click next

Step 8: A test would run against the database for the schema connectivity. Once you get a success for all the components proceed further.

Step 9: For a compact domain with a "Admin" only server which will host all the middleware services leave the defaults on step 9 and click next. If you have a need to update the configuration such as adding managed servers, update default ports you can check the appropriate configuration and update.

Step 10: Click Create to create a compact SOA domain

Step 11: Ensure the domain creation succeeds and click Finish to close the config wizard.

That completes the creation of a SOA compact domain.

Now, if you start the weblogic server by issuing startWebLogic.cmd command, you will notice that the Java DB instance would start automatically. Since this is a compact domain and it will run off the Oracle XE database instance, we don't need the Java DB.

Start the weblogic with the noderby flag to prevent the Java DB from starting up.

> cd $ORACLE_HOME\user_projects\domains\compact_domain\bin

> startWebLogic.cmd noderby

Once the server starts up, establish connectivity to all the services to test the installation;

WLS Console: http://localhost:7001/console

EM Console: http://localhost:7001/em

SOA Composer: http://localhost:7001/soa/composer

B2B Console (if installed): http://localhost:7001/b2bconsole

BAM Console: http://localhost:7001/bam/console

One advantage with compact domain is that you can also create a integrated weblogic domain from JDeveloper which could be handy for a lot of development activities.

SOA 11g MDS - Share Common Artifacts

As promised on my previous post, I am detailing the step-by-step instructions which allows for sharing of common artifacts (schema files/WSDLs) among SOA projects and more importantly helps in loose coupling of service bindings & remove service dependencies.

A typical use case is where the abstract WSDL definition of an external service can be stored in MDS and referenced from the SOA composite which will loosely couple the services and also guard against 'SOA Composite Invalidation' issues.

SOA 11g provides us with MDS repository (both file based & DB based) where common artifacts can be stored and referenced by all projects in the SOA infrastructure.

File based MDS is used during design/deploy time where as DB based MDS is used at run-time by the SOA infra. A configuration file named adf-config.xml that is part of every SOA project manages this partition mapping to be used by JDeveloper during design/deploy time.

All SOA projects that are deployed on the SOA infrastructure are stored in the MDS repository. If you create a connection from the JDeveloper 'Resource Palette' to the SOA MDS, there will be a 'deployed composites' folder which will contain all deployed artifacts.

Connection Information for the MDS connection:
username: XXX_MDS (usually DEV_MDS)
password: xxxxxxxxx
MDS Partition: soa-infra

The file based MDS repository is generally the 'seed' partition under a typical JDeveloper install;

<JDev_Home>\integration\seed


Under this partition there is a root folder (soa) available by default which contains all the configuration files, schemas & WSDLs required by various different SOA components during design time. These files are also pre-deployed on the database MDS repository.

We are now free to create custom folders under the 'seed' partition to hold artifacts that are common references in a SOA environment. Generally, we create an 'apps' folder under the 'seed' partition which in turn holds various folders to hold various artifact types;

 Once the artifacts that needs to be shared/referenced are placed under the appropriate namespace (in this case 'apps'), we can let the SOA project in JDeveloper to point to MDS for these artifacts from a common location.

adf-config.xml configuration:

As noted earlier, adf-config.xml is an important configuration file which holds the details regarding the MDS (both file based & DB based). By default, this file declares the 'seed' partition & the metadata store for 'soa' namespace.

This file can be found under <YourApplication>\.adf\META-INF.
Alternatively, in JDeveloper, expand the 'Application Resources' panel; drill through Descriptors -> ADF META-INF to find this file

Step 1: Just add the metadata store namespace for '/apps' in additions to default '/soa/shared' namespace - This is to let the JDeveloper reference the artifacts under the '/apps' during the design time from the file system metadata store.

<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
    <mds-config xmlns="http://xmlns.oracle.com/mds/config">
      <persistence-config>
        <metadata-namespaces>
          <namespace path="/soa/shared" metadata-store-usage="mstore-usage_1"/>
          <namespace path="/apps" metadata-store-usage="mstore-usage_1"/>
        </metadata-namespaces>
        <metadata-store-usages>
          <metadata-store-usage id="mstore-usage_1">
            <metadata-store class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
              <property name="metadata-path"
                        value="${oracle.home}/integration"/>
              <property name="partition-name" value="seed"/>
            </metadata-store>
          </metadata-store-usage>
        </metadata-store-usages>
      </persistence-config>
    </mds-config>
  </adf-mds-config> 

Step 2: In the SOA composite, reference the common artifacts from MDS as shown below;

 <import namespace="http://xmlns.oracle.com/bpmn/bpmnProcess/CreditCardProcess"
          location="oramds:/apps/orderprocess/common/CreditServiceProcess.wsdl"
          importType="wsdl"/>

Now that we have successfully referenced the SOA project to refer the file based MDS it is barely enough only during design time. For deploy time & run time, these artifacts must be made available in the DB based MDS.

There are two methods available for us to deploy the artifacts in SOA DB based MDS;

Approach 1: Ant based script which allows to deploy the artifacts into SOA MDS. I am not going to get to the details of this as this has been blogged in detail by Edwin Biemond; Reference below;

http://biemond.blogspot.com/2009/11/soa-suite-11g-mds-deploy-and-removal.html

Approach 2: For a simple JDeveloper based SOA deployment follow the steps below;

Step 1: Create a new application (Generic Application)

Step 2: Name the application (eg., OrderProcessMDSApp) and click 'Next'

 Step 3: Provide a name to the project (eg., OrderProcessMDSProj) and click 'Finish'

 Step 4: Now, right click on the OrderProcessMDSProj and choose 'Project Properties'. In the 'Project Properties' dialog, choose 'Deployment' and create a new deployment profile by clicking on 'New...' button

 Step 5: In the 'Create Deployment Profile' dialog, leave the default 'Archive Type' to 'JAR File' and name the deployment profile (eg., soamdsarchive) and click 'OK'

 Step 6: This will open up the 'Edit JAR Deployment Profile Properties' dialog. Click on the 'Contributors' section under 'File Groups -> Project Output'.

Step 7: Click on the 'Add..' button and choose the folder where the 'content to be deployed' is present. Here the '/apps' namespace under the file based MDS can be chosen where the content is already placed & available.

Step 8: Now, click on the 'Filters' section and choose the artifacts under the '/apps' that you would like to deploy or upload to MDS database repository

Step 9: Click on OK to complete the deployment profile creation process. Now, we have created a project JAR deployment profile which contains the artifacts to be deployed on to the SOA MDS. Now, we will have to create a application deployment profile of 'soa bundle' type which will be deployed to the soa-infra.

Step 10: From the 'Application Menu', choose 'Deploy' -> 'New Deployment Profile..' option

Step 11: Under the 'New Gallery' go to 'Deployment Profiles' choose 'SOA Bundle' and click OK

Step 11: Under the 'Create Deployment Profile', provide a name to the application deployment profile (eg., soabundle1) and click OK.

Step 12: In the 'SOA Bundle Deployment Profile Properties' go to 'Dependencies' and choose the JAR archive that we created earlier eg., soamdsarchive and click OK

Finally, deploy the application to the soa server. This will ensure that the artifacts under the '/apps' metadata namespace is deployed on to the SOA MDS database repository.

You can verify the same from the SOA MDS connection created under the 'Resource Palette'. This should now reflect the 'apps' folder at the same level as 'soa' metadata store.

Now, if you try to deploy the SOA project which references MDS you may hit a deployment error complaining that the resource referenced is not found. This is because the JDeveloper consults adf-config.xml configuration file during design & deploy time (refer back to the initial architecture diagram). Since there is no information about the DB based MDS in the adf-config the deployer complains.

To fix this, go back to the adf-config.xml file and add the DB metadata store information so that the deployer can read & locate the referenced resources from MDS.

<adf-mds-config xmlns="http://xmlns.oracle.com/adf/mds/config">
    <mds-config xmlns="http://xmlns.oracle.com/mds/config">
      <persistence-config>
        <metadata-namespaces>
          <namespace path="/soa/shared" metadata-store-usage="mstore-usage_2"/>
          <namespace path="/apps" metadata-store-usage="mstore-usage_2"/>
        </metadata-namespaces>
        <metadata-store-usages>
          <metadata-store-usage id="mstore-usage_2">
            <metadata-store class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
              <property value="DEV_MDS" name="jdbc-userid"/>
              <property value="xxxxxxx" name="jdbc-password"/>
              <property value="jdbc:oracle:thin:@hostname:1521:orcl"
                        name="jdbc-url"/>
              <property value="soa-infra" name="partition-name"/>
            </metadata-store>
          </metadata-store-usage>
        </metadata-store-usages>
      </persistence-config>
    </mds-config>
  </adf-mds-config>

That completes our configuration and eventually this elaborate post. Now, the deployment will be smooth as we have referenced the DB MDS in the adf-config.xml file.

Hope this post helped you understand & implement the SOA MDS related activities. Let me know your feedback through comments.