What’s a Database Back-End good for when you can’t view the data in any practical way ?

Naught, exactly.

I’ll spare you just how pleased I am that OfaDB now has a proper graphical interface.
Let me go ahead and tell you what it does, and you’ll understand right away.

Did you know that …

  • Ofa 3 now seamlessly logs details and hash sums on every log file, source file, input file – even generated and output files, and sends them all to OfaDB.
    As you’d expect, level of detail is controlled via Ofa’s astute fine-grained settings management.
  • OfaDB stores and crosslinks all those files and details in its tables.
  • All (logged) execution variables, warnings and error messages are equally stored, checksummed and cross-linked to the log.
  • Data recorded in OfaDB is highly tamper-proof.
    You can tell with absolute certainty which exact copy of any logged file was used in a run.
  • You can upload all available log files of your ofa 2 batch history.
    This will give you starting material for some insight into your operational history like you never knew was possible.
    And a sense of the position you’ll be in with the vastly more complete Ofa 3 data …

Okay, then you must have read the previous post about OfaDB.

Now: APEX’ Power

OfaDB’s Data Model is great: it stores every discrete element only once, and ties them together in an efficient, quasi-unfalsifiable way. It should scale big, thanks to all its foreign keys being based on indexed hashsums. As a DBA, I am pleased with the result – yes I am.

To tap into that amazing wealth of valuable information, most obviously an effective interface is needed. And, as far as I’m concerned, one that gives me a straight path to what it’s all about. Therefore, OfaDB’s Data Model was designed with APEX in mind.

APEX is the obvious choice. It’s safe to say that no other application engine lets you slice and dice your data more quickly and efficiently to your heart’s desire. You can knock up an application in a matter of hours that puts the most stunning reports on your data at a mere few clicks of the button.

OfaDB comes with one that should become indispensable from day one:

  • View any past period of any and all Ofa jobs, all in one list.
  • Filter on status, app, environment, server, you name it.
  • Drill down to full logs, sources, warnings, errors, variables, configuration files, input or output data in a few clicks.
  • Graph, list, aggregate them.
  • Download them raw, as pdf, as csv, or view them right in the browser.
  • Know differences, drifts and variations instantly.
  • Monitor execution times, error quotes, seasonal peaks and events.
  • Save your private custom reports and filters.
  • Prove your point, crack the knack, spot the pattern, score the growth.
  • The list goes on …

To be honest, OfaDB with APEX brings you as close as you can get to Absolute Traceability.
Pretty close, that is. Closer than anything I’ve seen or heard of.

In Ofa

In your operational environment, nothing much has changed.
A few parameters were set in the core, one job set up for collection.
In- and output files to ship are flexibly set in your scripts’ usual parameter files.

Logs now come out in two formats: XML + plain (post-processed).
Console output and mail stay about the same.
No script needs changes, no performance hit ensues.

The loader hashes, registers and copies (new) source and input files to the queue.
The log checker does the same with output files.
The master collects everything into staging and OfaDB slots them in.
That’s it, no tricks.

You just point your browser at OfaDB, coffee in hand, feet on desk – knowing you have a new instrument at your disposal now for morning meetings, night time fun, trouble shooting, auditor soothing, fact checking, chicks netting – all the while having more time for kiddies, spouse and house… and maybe just maybe, discover new beauty in life.

The story doesn’t end there. Detailed graphical information about OfaDB is due to come soon at www.onobase.ch.
I expect the Ofa revolution to break out any time now – be sure not to miss it.

Sincerly Best,

Olaf, your Ofa Oaf.


Ofa’s just got a DATABASE BACK-END

New in V3: OFADB

This should have been there from the start : the Database Component. Ofa is a shell framework for DBAs, right ? So why wasn’t it designed to include a repo DB from the outset ?

The answer is, it was !

Actually, the ofa is the re-crafting of several generations of Unix environments developed for DBAs over the years. One of those comprised a complex delivery and roll-out system featuring an advanced Database Back-End. That tool, however, was too specialized, rigid and unwieldy both for use and maintenance, to survive.

Ofa set out to re-build itself from the ground up, with new exigences such as agility, as well as a whole new level of power and usability – read the manifesto here.

So the Database Back-end was planned, but it needed a grounding in the form of a self-contained and absolutely independent shell framework, which has come about in the guise of ofa V.2

The new Database Back-End is an added feature. It imposes no operational constraint on the existing shell environment, and next to no overhead – true to the ofa philosophy, as it were.

The possibilities it offers, however, are vast and enticing.

You are right in demanding why it hasn’t been around from day one.

What is it good for ?

Want to know what’s been running last night ? The other night, last year on the same date ? Overall, for a host, a DB, an environment, an application ?

Want to score execution times, error rates, batch activity over time ?

Want a secure and irrefutable trace of any job that runs in your environment ?

Want to trace evolution over time of scripts ? – downloadable, like in a version control system ? – but with absolute proof that the version advertised actually is the version that had run ? – and without the hassle associated with maintaining an upstream version control system ?

Want to slice and dice your batch history ?

Want to appease an auditor ? – Want proof yourself ?

Want to give developers way to look at logs ?

… you name it. That’s what it’s good for. Very good.

How does it work ?

Being the heir of a sophisticated roll-out environment (generations ago), stakes were running high: the new Database Back-End was required to deliver on promises of highest standards of traceability and accountability. Demands of guarantee for absolute trustworthiness were imposed unto the system. It ought to be unfalsifiable, carbon-solid, tamper-proof. A data warehouse for the most discerning middleware administrator, a reservoir of unshakable proof. A powerful tool. Highly automated, highly usable, highly manageable, highly efficient, highly everything !

Ofa V.3′s OFADB Database Back-End delivers on these stringent requirements with confidence and ease. It gathers all the operational metadata, scripts, resource files and logs in the background and loads them into its repository – two batch jobs are all it takes.

Depending on your requirements, it will include, for any given run, configurable incrementally:

  1. The relevant ofa log
  2. The relevant script and parameter files
  3. The entire ofa ecosystem in place during the run

Every item is check-summed live – as are any and all error and warning messages. Checksums of scripts and parameter files are recorded in the log, which itself is check-summed. In the the OFADB Repository, all Items are linked via their respective checksums, which can be verified at any given time – manually, via update triggers or dbms job – depending on your security requirements: to every checksum corresponds a binary object in the database, and each and every checksum is part of a chain of integrity constraints. That, along with the regular database backup, makes tampering with OFADB virtually impossible – undetected that is…

Moreover, possibilities of mining the data are formidably enhanced by the all-pervasive presence of indexed checksum references. This makes OFADB a very secure, yet highly efficient and practical Data Warehouse.

OFADB vs. Other Systems

Okay, there are a lot of alerting, notification and monitoring systems out there. Isn’t OFADB redundant with those ? Isn’t there a sense of overkill here ? Has the ofa gone over the edge ?

Obvously, only managers would ask such silly questions ! Those guys have no idea !

No-one wants to take your Nimsoft, Patrol or any of those great industry-standard infrastructure tools away from you.

Ofa is a niche product, a glue product, a middleware enhancement – albeit a formidable one.

Try and ask for downstream version control and bullet-proof execution history of your every little script from those tools. Come back to me with the answer, I’d be interested.

Ofa V.2 already bestowed extraordinary power upon the Middleware guys.

Ofa V.3 propels that to yet another level. It demonstrates what the ofa is really capable of. Benefits are exponential in every stage of development.

In short:

Ofa*Vn = Bangn/Buck

Go for it.


Total Traceability