SelfDiagnose and OGNL and check your deployment

Some time ago I wrote about selfdiagnose-the-world-according-to-my-atg-application.
Since then SelfDiagnose has added some nifty features. The latest release of SelfDiagnose now adds support for OGNL. This gives SelfDiagnose some extra punch. I can now use constructions like:

<checkvaluematches
    value="${@java.lang.Integer@parseInt(configList.length)}"       
    comment="Number of configured Endeca instances"
    pattern=".*" />

or constructions like

 <checkendecaservice host="${configList[0].host}" 
   port="${configList[0].port}" 
query="N=0" 
  comment="Endeca instance 1 connection test"/>

The ${configList[0].port} is a typical OGNL construction.

The CheckEndecaService can also return the Endeca com.endeca.navigation.ENEQueryResults response.
With OGNL you can easily dissect this Endeca response.

This can be extremely handy to query for the latest Forge or pipeline version of an Endeca build in the different ATG environments were you cannot directly access those services! For instance in production.

SelfDiagnose, the world according to my (ATG) application

We have all been there, when developing a J2EE application, the environment nightmares. When your stuff goes through the different stages of integration, acceptance, production etc. Stuff just breaks^TM, because of misconfiguration. Configuration which you have no control over.

Missing a database table here, a JNDI binding forgotten, a URL not reachable, weird classloading nightmares, because another jar is being used in acceptance.

Here is where SelfDiagnose comes to the rescue. Somehow this little gem gets no press whatsoever. Lately some new tasks have been added to the mix. This blog by Ernest explains something about compile-time dependencies. But more interestingly (to me), SelfDiagnose now contains an CheckAtgComponentProperty task and a CheckEndecaService.
The CheckAtgComponentProperty lets you check an ATG property. I know this can be done with ATG’s component browser as well, but hold on.
The CheckEndecaService will check the availability of the Endeca service.

The combination of these tasks and the chaining of these creates a powerful diagnosis. See the following snippet of code, where first an ATG property is queried which then is chained to the Endeca task. Another nifty SelfDiagnose feature.
This code is heavily customer oriented, but you will get the idea.

    1 <checkatgcomponentproperty
    2     component="/wsp/common/services/search/balancer/connections/EndecaConnection"
    3     property="host"
    4     comment="Endeca Host"
    5     var="eneHost"/>
    6 <checkatgcomponentproperty
    7     component="/wsp/common/services/search/balancer/connections/EndecaConnection"
    8     property="port"
    9     comment="Endeca Port"
   10     var="enePort"/>
   11 <checkendecaservice host="${eneHost}" port="${enePort}" query="N=0"/>

The real cool and not so well understood part about SelfDiagnose in my opinion, is that it will check a bunch of tasks from inside the environment you are executing. This means that the above example will output the ATG configuration and check the configured Endeca instance of the actual environment.
Hitting the selfdiagnose.html url will show:

I just mentioned the ATG and Endeca tasks, but there is a lot more which can be extremely helpful.
This nifty feature can save some energy when something is misconfigured. Checking the selfdiagnose URL can save a lot of time.

Daring Devious Darryl Dude Needs Feedback and a bit of money along the way

Are you living in the Netherlands and need a book, a nice Cd, perhaps a Dvd, the latest Wii game or what have you, use the this affiliate thingabee. You will make Darryl happy.

I know I will use it.

Darryl’s commuting habits need a faster car.

Endeca dimension specifications

The next post is about some trivial XML parsing. Since it is uses Endeca definitions, which is not Google friendly perhaps it is useful.

Endeca spec

When using Endeca for search and guided navigation it of course often happens that Endeca is implemented and the specification is trundling behind.

During discussions with business representatives about Guided Navigation (aka dimensions and precedence rules) a bit of documentation is definitely necessary due to the dynamic behaviour of Endeca. That dynamic behaviour can be a tough cookie to demo. So a functional description becomes necessary.
Especially so when a test team comes along and wants the specification in a human readable form, perhaps to write the test scripts.

So I wrote a little Ruby script which parses the Endeca dimension files as produced by Endeca Developer Studio and dump them as a tab separated dimension hierarchy.

This produces

like structures.
A bit of extra text and you are good to go.

I wonder

Will the test show a difference between the specification and the implementation? This can be a nice test of the test script.