How to do versioning with Oracle Business Rules

In one of my discussions on oracle business rules, one query that I got was on versioning, for example  a scenario in which clients major business rules are written in Oracle  business rules and  as per requirement it is modified at runtime using SOA composer. There were lot of transaction that happened in that period with new rules and later it was reverted back to old rules. How can we track the changes that went in so that it is easy for rolling back to previous versions, know how any versions/changes have been made on the initial business rules.

It is a valid query from the user perspective and oracle has the solution.

Runtime Versioning is supported in Oracle Business Rules using MDS. The rules dictionary is stored in MDS and if MDS has database as the backend instead file based repository then versioning is supported using MDS. Any changes made to dictionary are made visible to the application in MDS. The rule service engine (decision service) does this automatically.

There is also option of creating metadata labels for each release or each update which will be helpful (similar to tags in SVN). A metadata label is a means of selecting a particular version of each object from a metadata repository partition. This tag/label comprises of the document versions which were the latest versions at the time the label was created.
Labels that are created will be available till they are deleted explicitly using wlst commands. Automatic purging will not remove the labels. Same as versioning, labels are also supported only in database-based repositories. As a good deployment/promotion practice, you can create a label and then promote documents/rules associated with a metadata label. It will be easier to rollback to an earlier version in case you use create/promote label approach.

References

http://docs.oracle.com/cd/E21764_01/integration.1111/e10228/faq.htm#BGBEJGEI

Runtime invocation failing with .__OAUX_GENXSD_.TOP.XSD Error /duplicate elements in XSD

Recently I was working with BPEL process which had multiple service invocations and my job was to enhance it by adding some OSB invocations. When I started modifying the code for new service invocations and WSDL modifications, the process stopped compiling due to the .__OAUX_GENXSD_.TOP.XSD. It looked bit odd, one of the main issues was due to some shared XSD’s and some services had included the XSD’s some were importing it, some had different XSD implementations for same namespace. So after consolidating the entire included schemas and existing schemas the process started working.

The biemond blog was helpful. 

The problem I faced was when I starting testing, I had the location replaced at runtime and it started failing with the same .__OAUX_GENXSD_.TOP.XSD error. This was new to me as I thought it will be going through since all the wsdls will be looked up at compilation time. Each invocation will be different. But it isn’t so, so finally I had to tweak the abstract wsdl to make it concrete (by adding service tags) composite.xml and config plan for deployment.

Error stacktrace

Exception: Can not build schema 'http://geo.com/commons/schema/type' locate

d at 'http://geo.com/commons/schema/type.__OAUX_GENXSD_.TOP.XSD' [Cause=Can

not build schema 'http://geo.com/commons/schema/type' located at 'http://geo

.com/ commons/schema/type.__OAUX_GENXSD_.TOP.XSD']

Reference WSDL (named in location of composite.xml)

Add service tags in wsdl definitions and have a dummy address, which can be updated during deployment.

composite.xml

Add the the property endpointURI which will hold the runtime URI (without the ?wsdl)

Depoyment Plan(soa config plan)

In the deployment plan ,don’t update the location attribute to the runtime location, keep it your local wsdl.Update the endpointURI property to the environment specific URI.

Add separate search replace for the wsdl and update the location value to the environment specific URI

Environment is 11g PS4

Hope it helps

SOA Composer with DVM’s

DVM’s become a headache if you have shared DVM’s across projects and multiple people try to update it.SOA Composer helps you in maintaining consistency for editing and maintaining the DVMs by allowing users to access all DVMs through the console. The SOA Composer is an EAR file, which is installed as part of Oracle SOA Suite installation. It enables you to manage domain value maps at runtime. I will take you thru steps on how to use it.

Login using the below URL

http://hostname:port/soa/composer

To view domain value maps at runtime:

From the Open menu, select Open DVM.

It will list you all the DVM’s present in the server with Partition and Composite name. It will mention Composite Name if DVM is deployed along with the Composite. If the Composite is accessed from MDS store, then Composite name will be shown as N/A

Select DVM to view the entries in DVM

How to Edit Domain Value Maps at Runtime

The domain value map opens in an edit session.

To add rows:

1.    Click Add Domain Values.

2.    Enter values and click OK. The entered values are added to the domain value map.

To edit rows:

1.    Select the row that you want to edit.

2.    Click Edit Domain Values. Edit the values as required and click OK.

To delete rows:

1.    Select the rows that you want to delete.

2.    Click Delete Domain Values.

Saving DVM’s at Runtime

Every time a domain value map is opened in an edit session, a sandbox is created per domain value map, per user. If you save your changes, then the changes are saved in your sandbox.

1.    Click the Save menu item to save your changes. If your changes are saved successfully, you receive a notification message.

Undo Changes made to DVM’s at Runtime

You can also revert a domain value map to the last saved state.

1.    Click the Revert menu item. A confirmation dialog is displayed.

Commit Changes at Runtime

Once you commit the changes, runtime picks up the changes and saves them in the MDS repository. In a session, you can also save your changes without committing them. In such a case, the domain value map remains in the saved state. You can reopen the domain value map and commit the changes later.

Note :

In some scenarios customers prefer to keep all DVMs in one shared project and use these DVMs across all SOA projects. After DVM project is deployed to production, DVM values are added /modified from SOA composer. But when they try to add a new DVM to the shared DVM project and redeploy to production, it overrides all changes made through SOA composer. This is a typical scenario you should avoid while designing. In order to avoid this issue, try to use MDS for storing the DVM’s. If you have DVM’s @MDS we can always go ahead an export the updated DVM’s and modify the exported DVM for further usage.