rss
SOATUBE
Oracle
Custom Search SOABYTE here

Wednesday, June 30, 2010

Analyze SOA readiness for a company

















Six questions to analyze if your company is ready for SOA

In today’s extremely competitive world, any business needs a robust yet adaptable IT infrastructure. The growing information needs make it imperative to replace the old systems with new enterprise applications. And even enterprise applications need to upgrade from time to time. Your organization ends up spending a large amount of the IT budget in managing integrations with each new release and upgrade. You must protect the investments in existing applications and leverage the returns from existing systems. Only then your organization can improve the responsiveness of its changing business needs.

Tuesday, June 29, 2010

Import AIA 2.5 xsd files in to MDS repository of SOA 11g


















Steps to be followed to import AIA 2.5 xsd files in to MDS repository of SOA 11g


Pre-requisite:
SOA suite 11g is installed in the system.
Jdeveloper 11g with soa plugin is installed in the system.
SOA suite MDS repository is installed during SOA suite 11g installation.




1) Making a Local MDS Repository:
Go to seed folder under integration folder  in Jdeveloper folder.   In server, go to \Jdeveloper\integration\seed
Create a folder with name apps.   Create a folder aiafp under apps.
Copy AIA 2.5 EnterpriseObjectLibrary folder to \Jdeveloper\integration\seed\apps\aiafp.
Remove all the html files from EnterpriseObjectLibrary folder and its sub folders as only xsd files need to be imported to MDS repository.
Create a new MDS File Connection in Jdeveloper 11g with \Jdeveloper\integration\seed as MDS root repository.
Create new MDS file connection in Jdeveloper 11g with name AIA in the Resource Palette.  For this connection, local folder \ Jdeveloper\integration\seed is used as MDS root folder.
Once the SOA-MDS connection wizard is finished, a SOA-MDS connection AIA with files and folders in \Jdeveloper\integration\seed was seen in Resource Palette of jdeveloper.  This serves as local MDS repository.

2) Import local MDS files to the SOA Suite database MDS:
Downloaded mds.jar from http://biemond.blogspot.com/search/label/MDS to Jdeveloper folder. 
Unzipped mds.jar and opened the project bin in Jdeveloper 11g.
 Modified the adf-config.xml file (present in resources/config folder of bin project) by changing the database connection details to database connection details of the mds user.
Verified if path attribute value is /apps in the namespace tag in list of metadata namespaces.  This is valid value.
Go to Application resources window in Jdeveloper11g.  Navigate to ADF META-INF folder.  Open adf-config.xml and update property “metadata-path” value to\Jdeveloper\integration.
In above adf-config.xml, Verified if path attribute value is /apps in the namespace tag in list of metadata namespaces.
Opened build.properties present in bin project.  Modified the weblogic server details, weblogic server credentials, SOA domain name, and server targets and mds database user details in the build.properties.
Right-Click on common-sca-tools.xml.  Click on  “Run Ant Target” in the menu.   Click on importCommonServiceArtifactsIntoMDS to run the script to import the files and folders present in local MDS metadata located at \ Jdeveloper\integration\seed to target MDS present in database.



3) MDS Repository Connection - Access the xsd files present in SOA Suite database MDS:
Created a new database based MDS connection with soa-infra as partition.
In this new MDS repository, we can see the folder structure and files imported to MDS repository.
 The folder structure in database based MDS repository will be same as folder structure in local file based repository.
Verify if the xsd files are imported successfully by opening xsd files in database based MDS repository.

Considerations:
When an xsd file is updated in local MDS repository, running the script to import the files from local repository to MDS in database can synchronize the xsd file.
Make sure the folder structure is correct in local MDS repository before importing to target MDS repository in MDS database.
For Custom EBOs/EBMs place it in the respective folder structure, and run the script to import the files from local repository to MDS in database.

Business Rules 10g to 11g migration



















Before you can use a dictionary created with Oracle Business Rules Release 10.1.3.x with Oracle Business Rules for Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1), you must migrate the dictionary to the new dictionary format. Depending on how the Release 10.1.3.x dictionary was created, there are several possible migration paths to migrate a dictionary from Oracle Business Rules Release 10.1.3.x format to Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1).




Ø  Using Oracle JDeveloper to Migrate an Oracle Business Rules Dictionary

When a dictionary is part of an application created in a 10.1.3.x BPEL Decision Service, you can migrate to the Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) dictionary format when you open the BPEL process in Oracle JDeveloper.
1.       Start Jdeveloper.
2.      From File Menu, select Open
3.       Navigate to your project, and select Open. JDeveloper invokes the Oracle BPEL Process Manager migration utility to convert the project, including its rules dictionary.
4.      Examine the Messages – Log window for any errors.
5.       From the File menu, select Save All.
Ø  Using Rule Migrator Tool to Migrate an Oracle Business Rules Dictionary
You can use the MigrateRuleRepository command-line tool to migrate a dictionary from 10.1.3.x to Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) format. Note that most migration scenarios require that you perform manual migration tasks because 10.1.3.x has concepts that have been superseded in Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) by updated and more powerful constructs.
The command-line tool is a Java class called the following:
oracle.rules.tools.migrator.MigrateRuleRepository

It is located in the following directory inside the SOA Oracle home:
SOA_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar

To run the command-line tool, you must have the following set of JAR files available in the classpath.
JAVA_HOME/lib/tools.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jar
JDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jar
JDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jar
JDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar
The following shows a sample MigrateRuleRepository command:
MigrateRuleRepository -all
-origType FILE_REPO
-origLocation /scratch/MyRepository
-destLocation /scratch/MyMigratedDictionaries
-importedClasspath /scratch/foo.jar:/scratch/myclasses
-xsdDirectory /scratch/myschemas
-xsdGeneration /scratch/jaxb_classes
Ø  Using Oracle Business Rules SDK to Migrate an Oracle Business Rules Dictionary

To migrate a dictionary using Oracle Business Rules SDK,

1.       Start Jdeveloper.
2.      In the Application Navigator, click New Application
3.       In the Create Application wizard, enter the name and location for the new application. Click Next.
4.      In the Create Generic Application wizard - Name your Generic project page, enter the name and location for the new project. Click Finish.
5.       In Oracle JDeveloper, select the project with the new name.
6.      Right-click and from the drop-down list select Project Properties.
7.       Select the Libraries and Classpath item.
8.      Click Add JAR/Directory. You must update your project classpath with the following JAR files. Note that there may be a JAVA_HOME installed next to JDEV_HOME, in your ORACLE_HOME directory.

JAVA_HOME/lib/tools.jar 
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/migrator.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/rulesdk.jar
JDEV_HOME/modules/oracle.adf.model_11.1.1/jr_dav.jar
JDEV_HOME/modules/oracle.pki_11.1.1/oraclepki.jar
JDEV_HOME/soa/modules/oracle.rules_11.1.1/rl.jar
JDEV_HOME/soa/modules/oracle.rules.migration_11.1.1/webdavrc.jar
In the Add Archive or Directory dialog, select the required JAR file and click
9.      Click Add Library -You must add the following libraries to your project classpath:
BC4J Client
Oracle JDBC
Oracle Rules
Oracle XML Parser v2
 JAX-RPC Client


10.   In Oracle JDeveloper, select the project with the new name.
11.    Right-click and from the drop-down list select New.
12.    In the New Gallery, in the Categories area, select General.
13.    In the New Gallery, in the Items area, select Java Class. Click OK.
14.   In the Create Java Class window, configure the following properties
 Enter the Name value - Name of the Java class.
 Enter the Package value – Name of the package
Check the following check boxes:
– Public
– Constructors from Superclass
– Main Method
                Jdeveloper creates the required Java class.
15.   Use MigrateRuleRepository API to create the required code for the Java class.
16.  If the repository you are migrating contains XML Fact Types, you need to specify the location of the schema file that defines these XML Fact Types, and also the output directory that JAXB should use when converting schema files into Java classes.
17.    In the Application Navigator, right-click .java and select Make.
18.   In the Application Navigator, right-click .java and select Run.
19.   Examine the Messages - Log window for any errors.
20.  Retrieve the migrated dictionary from the destination location.


Ø  Oracle Business Rules Manual Migration Tasks
Certain migration scenarios like migrating dictionaries using JAXB1.0 in 10g to 11g require manual migration tasks.

How to Migrate JAXB 1.0 to JAXB 2.0
Oracle Business Rules Release 10.1.3.x uses JAXB 1.0 by default and Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) uses JAXB 2.0. Rules Designer 11g only allows XML schemas to be imported using the JAXB 2.0. However, migrated dictionaries can continue to use JAXB 1.0, but the schema cannot be modified or reimported as JAXB 1.0. A migrated dictionary which uses a JAXB1.0 objects still works with Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1).

To migrate JAXB 1.0 to JAXB 2.0:
    1. Use Rule Migrator to migrate.
    2.  Delete all classes in SCA-INF/classes.
    3.  Record the aliases assigned to all of the fact types used in your rules.
    4.  Delete from the data model the XML Fact Types you want to upgrade to JAXB 2.0. This operation can result in a large number of validation warnings, one for every reference to the now-deleted fact types. However, the SDK stores references to both the ID and String value of all referenced elements. 
If the reference ID is set and it exists, then the String value is updated to reflect its current alias. So, if the alias of a fact type is changed, all of the places where that fact type is referenced get the new value because of the reference id.
If the element with the ID is removed from the dictionary, the String value retains the last known name of the referenced element. This allows you to, for example:
1. Delete a fact type with alias "FactType1"
2. Import a new fact type.
3. Set the alias of the new fact type to "FactType1" and all of the references to the deleted   fact type automatically change to the new fact type.
    1. Import the schema.
    2.  Set the alias of the fact type to the previous alias.
    3.  Run validation on the dictionary.
    4.  If desired, set the alias of the fact type back to the original alias.
    5.  Confirm that all of the references are now be updated.


How to Migrate RL Functions:
In the previous release, the only option for creating a Function was to write free form RL. These functions relied on generated RL names, which have changed in 11g Release 1 (11.1.1): the RL names are now automatically computed from the alias so they are RL-compliant, instead of relying on the user to provide a valid name.
You must re-write any function which accesses globals to comply with this change by using Actions. It is easier to write functions using Actions because they are validated at design-time.
In Oracle Business Rules Release 10.1.3.x dictionaries that contain free-form RL functions, it was a common practice to refer to Java classes which were not in the data model. For example, many dictionaries include functions which use ObjectFactory to create instances of JAXB classes. In Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1), to include this class in the data model you cannot simply reimport the schema and import ObjectFactory because it is imported as a JAXB 2.0 class. The solution in this case is to use the ObjectFactory class which is in the "classes" directory in your project from when the dictionary was migrated. This ObjectFactory class should be imported as a Java class and can then be referenced in Oracle Fusion Middleware SOA Suite 11g Release 1 (11.1.1) functions.

To migrate RL functions:
1.       For each free form RL function, re-write the RL to use Actions.
2.      In 11g Release 1 (11.1.1) you may use Actions both in Function bodies and in rules.
3.       There are several new Action forms which in most cases eliminate the need for free form function bodies. Action forms available include:
Call
Assert and Assert new
Retract
Assign and Assign New
Modify
Synchronized
Expression
Assert
If, Else If, and Else
For and While
Return, Throw, Try, Catch, and Finally
RL
4.      Validate your dictionary.

Ø  Manual Migration
In the previous release, the only option for XML schema import was JAXB 1.0. In 11g Release 1 (11.1.1), Oracle Business Rules provides support for JAXB 1.0, but JAXB 2.0 is the default. If you choose to continue to use JAXB 1.0, generated RL may throw MultipleInheritanceException. The SDK does not do any validity checking on free form RL Function bodies. As a result, any errors in the functions are not revealed until the RL is executed.

Domain Value Maps 10g to 11g migration




















In case of Domain Value Maps (DVMs) or Cross References used in Oracle BPEL Process Manager 10g or Oracle Enterprise Service Bus 10g projects,
The xPath functions used to access the domain value maps or cross references are upgraded automatically to Oracle BPEL Process Manager and Oracle Mediator 10g when the projects are opened and upgraded in Oracle JDeveloper 11g.
However, a manual upgrade task has to be performed to upgrade the domain value maps and cross references that are saved in the Oracle Enterprise Service Bus repository. 





The upgrade process moves the domain value maps from the ESB repository to the Oracle Fusion Middleware SOA Suite 11g Metadata Services (MDS) repository.

Task 1 : Export the domain value map metadata to a ZIP file
1.       Change directory to the Oracle Enterprise Service Bus Oracle home.
2.      Use the export script to export the metadata to a ZIP file.
For example, on UNIX systems:
ORACLE_HOME/export.sh metadata10g.zip
Task 2 : Convert the ZIP file to an Oracle SOA Suite archive file
Use Apache Ant and the upgrade-xrefdvm target in the sca-upgrade.xml file to use the metadata ZIP file to generate an Oracle SOA Suite archive JAR file:
1.       Change directory to the Oracle SOA Suite 11g Oracle home.
2.      Use the following command to generate a SOA archive file, which will automatically be called sca_XrefDvmFiles10g_rev1.0.jar:

ant -f ant-sca-upgrade.xml upgrade-xrefdvm
-Dsource=location_of_the_zip_file
-Dtarget=location_of_the_soa_archive
For example:
ant -f ant-sca-upgrade.xml upgrade-xrefdvm
-Dsource=$ORACLE_HOME/temp/upgrade/metadata10g.zip
-Dtarget=$ORACLE_HOME/temp/upgrade
Task 3:  Import the archive file into MDS repository
1.       Start Oracle JDeveloper 11g and create a new application.
2.      Import the Oracle SOA Suite archive into a new SOA project:
a.        From the Oracle JDeveloper 11g File menu, select Import, then SOA Archive into SOA Project.
b.       In the Create SOA Project from SOA Archive Dialog Box, click Browse and locate the sca_XrefDvmFiles10g_rev1.0.jar file that you created previously in this procedure.
c.        Make sure that the Project Name and Composite Name in the Create SOA Project from SOA Archive dialog box have the same name, which must be XrefDvmFiles10g.
d.       Click OK to create the new SOA project, which is called XrefDvmFiles10g.The new project consists of an empty composite, along with the upgraded XRef and DVM files.
3.       Create a metadata archive (MAR) file for the application, which includes the Xref and DVM metadata, and then deploy the MAR to the Oracle WebLogic Server domain.
For information about creating a MAR, see "Creating a Deployment Profile" in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework.
 After you upgrade the DVM and cross reference metadata to 11g, you can then use Oracle JDeveloper 11g to modify the entries in the XrefDvmFiles10g project as needed. Each time you make changes, you must then transfer them to the proper MDS repository using the MAR deployment process.

Oracle SOA Suite 11g Command-Line Upgrade tool


Ø  The Oracle SOA Suite Command-Line Upgrade Tool has the following benefits:
o   The command-line tool automates the application upgrade work using scripts.
o   The command-line tool upgrades both Oracle BPEL Process Manager projects, and upgrades Oracle Enterprise Service Bus 10g projects to Oracle Mediator 11g.
o   With the command-line tool, BPEL projects can be merged together and created as a single composite out of multiple BPEL projects. This is not possible while using the Oracle JDeveloper Migration Wizard.
o   The functionality is exactly the same as the JDeveloper mode when it comes to dealing with SOA project contents because the same codebase is used.



Combining Multiple BPEL Projects into a Single Composite with the Oracle SOA Suite Command-Line Upgrade Tool

Using the Oracle SOA Suite Command-Line Upgrade Tool, BPEL projects together can be merged and created as a single composite. This is not possible while using the Migration Wizard in Oracle JDeveloper.

To combine multiple BPEL projects into a single composite, provide multiple source directories as part of the -Dsource property on the command line. Path separators can be a colon (:) or a semicolon (;). Ant will convert the separator to platform's local conventions. As a guideline, also use double quotes to identity the multiple source directories to prevent Ant from parsing the input in an unexpected manner.

The first source directory specified will be considered as the root of the 11g project and will determine the composite name.
For example:
ant -f ORACLE_HOME/bin/ant-sca-upgrade.xml
-Dsource "sourceDir1:sourceDir2"
-Dtarget targetDir
-DappName app_name

The first project in the source list is considered the root project and only those services are exposed as Composite Services. Anytime you use the merge feature, it is recommended that the projects be related.

Note: Merging of projects is supported for BPEL projects only. ESB projects cannot be merged with other BPEL or other ESB projects.

Upgrading Oracle SOA Suite Client Applications




















The client applications that depend on the 11g SOA applications should be reviewed, upgraded and tested.
Use the following list to analyze client applications for required updates that will allow them to work with newly upgraded 11g Oracle SOA Suite environment:
Ø  Review the client applications to understand which remote Oracle SOA Suite APIs they are using.
Ø   Search your client applications for any references to Oracle SOA Suite HTTP URLs. The syntax of the Oracle SOA Suite 11g HTTP URLs has changed from 10g. To obtain the new URL that a client can use to access a deployed Oracle SOA Suite 11g application, use the home page of the application deployment in Oracle Enterprise Manager Fusion Middleware Control. 

 
Blogger Profile