Archive for September, 2007

Part Two – Compiled vs. Config

I remember back when I first wrote an application professionally; it seemed highly complex and well thought out, and I thought I had all the customer requirements covered off. Then came deployment and bang, my app hit the real world and a huge problem. All the details were hard coded and based off my development machine not the production environment. Horrible. Quickly I learnt (over many, many cups of coffee) that I should use configuration files so that details such as database connections, usernames/passwords and so on could be altered.

Later I learnt an important lesson in application design. Things are NEVER static or fixed. A customer had a list of codes that defined various subdivisions of properties they owned. I suggested these should be in a database so if they changed the application would not break. I was repeatedly assured they never change. Against my better judgement, I backed down and hard coded the values. The day of go live, the codes changed. Fancy that. Lesson learnt.

Now you may be reading this and thinking well obviously these elements should be stored in a configurable way. You might even be thinking, idiot. But before you give up on me completely I would like to point out that every day, almost every single solution I have come across hard codes volatile logic and business description. In fact it could be pointed out that the tendency to use object models and relational databases for every application leads to customer dissatisfaction since they are constantly stuck in a cycle of change management. In fact a common complaint I hear is that the software they procure/write/inherit is incapable of keeping up with the speed of changes in their business.

So is there a better way?

 I think so. A combination of a few emerging and existing technologies offers the ability to build applications that hard code only the supporting functions (think logging, security etc) whilst providing a flexible framework to host the business functions. Let’s start off with business logic.

Currently this tends to be expressed through detailed object models that expose methods and properties to other object. These models can be extensive but crucially bury the core business processes in the model. When business changes, as it usually does, these models must be updated. Often this can be painful, and usually it is expensive. What if the business process was represented in a more decoupled and configurable way? What if a core workflow engine could consume business process descriptions and orchestrate the invocation of component functions in a way that did not require direct dependencies? What if business rules could be stored and expressed in a non-code manner that would enable businesses to directly alter their own rules without involvement of coding? Would that be a benefit?

Some of the components of this idea already exist. Business Rules Engines are available (BizTalk for example has one). Workflow solutions and engines exist. De-coupled invocation of business functions can already be achieved. So what’s required to bring the concept to reality? Actually, I don’t think a lot more is required. Just a change in the way we develop applications, and maybe a change in the way we see our roles supporting business. Although on the surface it could be argued that change equates to dollars for us, I would suggest that more flexible software would lead to more dollars through increased desire to engage.

So what about business data? Typically this is stored in a database within complex relational tables. Well and good, but changes to the business data lead to changes in the data model. And that gets complex. How do you account for legacy data in a new data model? What if the data needs to be retrievable in its original form? What happens with keys, and required fields that are missing?

For a while now I have been talking to a number of colleagues about the idea of using XML as native data types in SQL. This is especially attractive for complex message schemas such as HL7 v3.0. The core advantage here is versioning. Multiple versions of the model can co-exist on a single database, and legacy data can be accessed in it’s original form, often a requirement for medical data.

So just a few thoughts. But I am convinced that there are more examples and possibilities. Can a core app be built and then used to support multiple businesses? Is there really a need for 100’s of applications to be written every year to do the same job? Maybe not.

Tags: , , , ,

Powered by Qumana

Advertisements

Getting addicted to the stats page – “Map fails in custom pipeline”

I know, it’s wrong. But oh so interesting!

The latest search term I noticed that reminded me of a problem was "map fails in custom pipeline". This was the bane of my life in a past project and resulted in an additional 100+ orchestrations in the eventual solution. When developing a solution with the HL7 accelerator you cannot put a map in the pipeline. The basic issue is that if a message is received in the pipe-delimited HL7 format which cannot be disassembled by the HL7 pipeline component it is not converted to XML. The map expects XML as an input and when it receives the non-XML message it fails, collapsing the pipeline.

That is a bit of a pain, and more so with solutions based on the Canonical model that require the ACK/NACK generated by the pipeline. Specifically if the pipeline collapses prematurely then the ACK/NACK is not written to the MessageBox and therefore never returned to the upstream system. Which then generally sulks and does nothing.

The solution is to place the map in an orchestration after the pipeline has completed. Which lead to the 100+ orchestrations in my solution; one for every HL7 trigger for every upstream system. Not fun.

So if there are any other issues that lead you to my blog, leave a comment, and I’ll see if I can help!

Tags: , , ,

Powered by Qumana

“biztalk mllp does not work”

I was looking through the stats on the blog (not sure if that counts as sad or just narcissistic) and was amused to see the search term "biztalk mllp does not work" as one of the links to a post. Now I feel a bit bad as I don’t think I have written anything that would be of particular use to the searcher. So, if you happen to read this, post what the issue is. I’d definitely interested. Sometime picking up parts of this technology can be highly frustrating for no apparent reason!

As a matter of interest, I believe I have said those very words. There was definitely an issue in the released versions where the MLLP adapter would do "odd" things. The oddest would occur when the adapter had not received a message for a while. It would go to sleep and the first message it would receive would "wake" the port, but the message would be eaten without trace. Highly frustrating when you are developing/testing, and a problem not usually seen in a production environment where messages are received frequently enough to avoid this issue.

Check out the changes made to the MLLP Adapter in BizTalk 2006 R2; specifically to the Persistent Connection Management on MLLP send and receive. It’s now possible to set the connection to persist; ie. never close. This may well solve the issue.

Tags: , , ,

Powered by Qumana