Thursday, September 27, 2007

How to Dump Subversive Revisions

Most things in life you can more easily get rid of than an unwanted revision in Subversion. As Simon and Garfunkel sang, there are even 50 ways to leave your lover!

Now why is that so hard? It starts with the principle that revisions should build upon each other, and when necessary can be reversed with another revision, so there should be no need to do so. Subversion therefore is designed never to lose information. What this philosophy does not take into account is that sometimes people make mistakes, or even worse are clueless, and for example start to make changes and commit that to a branch instead of the trunk. Sometimes that happens not only once, but twice!

Of course you can argue that people should not make mistakes and the clueless should never be allowed to work with Subversion. Hey, I'm with you, but you need to start somewhere, and I found that many people find it hard to really understand how tagging, branching, switching and all works, and sometimes need considerable time to get there. So let's face it, shit happens and then we feel a need to dump that in the sewer.

If you ever need to do so, there are two ways. The first way is the official way, which works as follows. By the way, in my example I'm using TortoiseSVN as a client:
  • Make sure you are in the right trunk, tag or branch for which you want to undo some revision.
  • Using "Show Log" find the revisions you want to undo. You can multi-select revisions.
  • Right-click the selection and choose "Revert changes from this revision". This will revert all committed changes locally.
  • Commit that changes (make sure that this time you are committing to the right URL!)
  • If you switched before you started, don't forget to switch back to the HEAD of the trunk afterwards.
The second way is the "hard way", which consists of making a dump of the repository using the svnadmin dump command of the command line tool. When using that, you can make a dump of a specific range of revisions and leave out the revision(s) you don't want using the -r [lower rev[:upper rev]]switch. After that you create a new repository and load the dump into that using the svnadmin load command.

There are a couple of issue with the hard way. First of all, unless you physically remove the folders of the old repository, the old repository will still be there. And people need to be aware that they need to go to a new repository instead. Of course you can tweak that manually by first deleting the folder of old repository and then create a new one using the same name and only after that load the dump back again.

Secondly, the hard way as described, provides no solution for the situation in which you want to remove a revision from some branch while in the meantime a new revision has been created in the trunk, because you cannot provide a set of ranges while dumping. That can be tweaked by making another dump containing the latest revisions and manually "merge" that with the other dump, but that can get complex.

Finally, the repository might have become a big mama and dumping and loading that can take considerable time.

So my conclusion: you need to have a damn good reason not to do it the official way. I'm therefore most interested in the rumor I've heard, that they plan to introduce the svnadmin obliterate command. Hopefully does that allow for removal of a complete revision as well.

Tuesday, September 18, 2007

Business Rules as Usual

There will be some enhancements in the Oracle SOA Suite 11g regarding versioning of rules for Oracle Business Rules. Until then we will have to do with versioning of dictionaries and repositories. This topic will address some best practices I have with versioning and Oracle Business Rules 10.1.3.x.

Versioning of Dictionaries

Versioning of dictionaries aims at rules administrators, which can either be a business analyst or a developer. Versioning of a dictionary is done by saving a particular dictionary using another version number. Sounds trivial, not? Think again. The dictionary probably will work in combination with some application calling the rule engine, providing it with a particular version number to work with. So if you want to change something that should be effective immediately, you should save the dictionary using that particular version number. But what if there is a problem and you want to revert to the previous version? Or would you not rather want to be able to test your changes first before disrupting production? In other words, you want to be able to use at least two different versions: one to be used for testing and one for real.

What I always have is two dictionaries, one version for example with number 2.1.0 for production and another one with number 2.1.x for testing purposes. The test version I can always recognize by the 'x' at the end. Which version the application is supposed to work with, is read from a properties file that I can change on the fly. What I also could do, is create some preference screen through which the rules administrator can select the version to be used during a particular session, the one from the properties file being the default.

As property files can be written, that screen could easily be enhanced to allow changing the default. In this way the rules administrator will have a way to change existing rules or add new ones and test them first, before bringing them into production. The latter can be done by either overwriting the 2.1.0 dictionary with the 2.1.x version, or by saving the 2.1.x dictionary as 2.1.2 and set that as default. The rules administrator will also have the option to activate particular rules for a specific period of time, by putting them in a specific version, and set that as default only during that period.

Versioning of Repositories

Versioning of repositories aims at developers. The prime reason you might want to version repositories, is that during maintenance of the application the fact definitions may change. Fact definitions are dictionary specific, so why not version dictionaries instead? Of course you also use a particular dictionary to make the changes, but obviously you want to make sure you keep a clear track of what version of a repository works with what version of the application. And of course you are using some proper source control system like Subversion to manage you configurations, right? Right! And as that system probably is file based, you want the dictionary to be in a file you can put under version control, obviously.

So what I do is that with every change (or set of changes) I make and that have been properly tested, I make an export of the rules repository and commit that to the repository of the version control system together with the corresponding sources (XSD's or Java classes).

And business rules as usual.

Tuesday, September 11, 2007

Analize This Business Rule!

Last week I attended a session in which the new-to-come SOA Suite 11g was being presented by Clemens Utschig-Utschig to Oracle Partners as well as internal employees.

Many great new things to come, like:
  • One integrated SOA Suite
    Regarding the versions up to 10.1.3 the SOA Suite consists of (at least) four different products (BPEL, ESB, BAM, OWSM) that happen to be on one installation CD and 'coincidentally' get all installed during one installation. With 11g this will have changed, from an architectural point of view as well as presentation-wise. For example, ESB will have become part of the infrastructure of the SOA Suite (taking care of routing requests to services), rather than a component on its own. And instead of four different consoles (that not only look like they have been created by independent teams, but probably are as well) there will be one integrated console.
  • Many enhancements regarding versioning, deployment and unit-testing of services.
  • Multiple BPEL processes in one project (and the possibility to drill down from one BPEL process to subprocesses)
Just to name a few.

One thing that I have not mentioned but for some reason want to point out in particular, is the fact that JDeveloper 11g will have the Rule Author of Oracle Business Rules integrated in the IDE. That's right folks, with 11g you will be able to connect to and maintain a rules repository using a Swing client rather than the current web client. Clemens did not demo that, so I can't tell you much about how that works, but at least it looked promising. Can't wait to get my hands on that!

But at the same time it raised the question what this means for having a 'stand-alone' Rule Author aiming at business analysts that (given the promise of rule engines and introducing agility to business rules with that) you would expect to be an important user group of rules engines. Not that I have seen that work in practice yet, but that is the promise. Will that disappear, meaning that we have concluded that we want business analysts keep their hands off rules repositories, at least not as long as Oracle Business Rules is concerned?

Fortunately, we seem to be working on a browser-based rule authoring tool as well, aiming at business analysts or any other user that for some reason you do not want to get starting to use JDeveloper. Off course, priorities, hurricanes or Bush eating a pretzel can change that any second, but I have not given up hope for business rules and agility yet!

Monday, September 10, 2007

Oracle Rule Author on Stand-Alone OC4J 10.1.3.x

For quite a while I could not use Rule Author anymore on my stand-alone OC4J, the reason being that I was not able to connect because of the error '[code=CANT_CONNECT_LOOPBACK] Cannot connect due to potential loopback problems'. I thought, as the loopback problems are only potential, why not give it a try and see how far we get. But my computer thought differently and refused to cooperate.

So I Googled this error, found quite a few links, none of them useful to resolve my issue. As issues like this can easily take a lot of time, and as I had the SOA Suite with Rule Author already running in a virtual machine, I decided to leave it as it was and used that instead. That was, until my virtual machines started to freeze every now and then, especially in the middle of the heat. You can run, but you cannot hide, can you?

For some stupid reason it never occurred to me to search for the loopback problem on OTN, probably because I never associated this error message with Oracle Software. As such that assumption appeared to be correct, but a colleague of mine did nevertheless and found this topic on one of the forums. Boy, how silly I found myself to learn that it was related to the proxy exception list of my web browser! I must have checked that at some stage, but probably at the wrong moment. Arrgggh!

Anyway, as I now can connect again to my stand-alone OC4J again, I thought it would be nice to be able to avoid crashing virtual machines and all that. So I redeployed Rule Author like I was used to, that is using the ruleauthor.ear and rulehelp.ear files from my SOA Suite installation, only to discover that this did not work at all. Right. So, being a clever guy I searched OTN to see how to deploy Rule Author on a stand-alone OC4J, only to find ... nothing! But no panic, Google is still in the air, helping me to a topic that offered me the missing pieces on the IT-eye blog.

Difference with my situation is that I didn't want to install it on the embedded OC4J that comes with JDeveloper, as I want to be able to upgrade JDeveloper without needing to redeploy Rule Author again. So the following instructions are somewhat different to those of the IT-eye version:

Prerequisites:
  • ruleauthor_s.ear and rulehelp_s.ear
  • rl.jar, rulesdk.jar, webdavrc.jar, jr_dav.jar
The ruleauthor_s.ear and rulehelp_s.ear I got from the /rules folder of the SOA Companion CD 2, the jar files can be found in the [JDEV_HOME]/integration/lib folder of that same CD.

Steps to deploy (all paths relative to /j2ee/home):
  1. Using the Application Server Control, (re)deploy both the Rule Author and the help file with that.
  2. Create a /rules/lib folder and copy the jar files to that
  3. Configure a rules library in the /config/server.xml file of your OC4J instance, by adding the following code snippet to the shared libraries already configured:
    <shared-library name="oracle.rules" version="10.0" 
    compatible="true">
    <code-source path="../rules/lib/"/>
    <import-shared-library name="oracle.http.client"/>
    <import-shared-library name="oracle.xml"/>
    </shared-library>
  4. Add the oracle.rules library just created to the default set of shared libraries available, by adding the following line to the /config/system-application.xml file:
    <imported-shared-libraries>
    ...
    <imported-shared-library name="oracle.rules">
    <imported-shared-libraries>
  5. (Re)start your OC4J instance
Rule Author should now be up and running!

By the way did I already told you that I was able to fix the problem with my virtual machines by upgrading to the latest Workstation 5 version? No? OK, I was able to fix the problem with my virtual machines by upgrading to the latest Workstation 5 version. I hope.

Thursday, September 06, 2007

The End Is Near ...

... of our customers needing to wait for the Oracle Unified Method (OUM for short)!

Last week version OUM Release 4.4.0 has been made available internally, and I happen to know for a fact that this version will become available to customers. How exactly is yet to be determined officially, but it has already been packaged to be released, so that should not take very long.

And as you have been waiting for more than a year for this, you can bear another few weeks, wouldn't you say?