Contents tagged with SOAWeb Services

  • K2 "BlackPearl" Beta 1 TR2

    On Mach 26th, SourceCode Technology Holdings will release the Beta 1 Technical Refresh 2 of their k2_bp_default.gifupcoming K2 product code-named “BlackPearl”. If you’ve never heard of SourceCode they are best known for their workflow product called K2.NET. The new product is currently branded K2 “blackpearl” but there is no word yet on what the final name will be. I will just call it K2 from here on. You can get a preview of K2 at this teaser site.

    I spent some time at SourceCode’s North American head quarters in Redmond last week for some in-depth demos, and I was really impressed with what I saw. While the old K2.Net product was pretty nifty and quite successful (I blogged about it here), this new product is going to make K2 a world-class player in the workflow and Business Process Management (BPM) arena. In fact, this new product is so rich in functionality it defies description, and I think it breaks new ground that no competitors are covering yet, on any platform. As I was going through a demo of the new functionality my mind was racing, thinking of all the new possibilities this technology brings to the table. I was also struggling to come up with a concise way of describing it. After much reflection I came up with “Business Process Oriented Development Platform”.  Here’s why…

    K2 is still a workflow product (now built on top of Microsoft’s Workflow Foundation), but it also becomes a true BPM platform, something the old version was not. K2 is also strong as an Enterprise Application Integration platform (leveraging the new BizTalk/.NET Adapter Framework built on Windows Communication Framework). Last but not least, K2 is also an Application Server with strong support for rapid application development (leveraging SOA standards and principles, SQL Server, the .Net Framework, Visual Studio, and the Office Platform). So it is a complete application server and development platform with a strong workflow engine at its core, and a very flexible integration platform built-in.

    There is way too much new functionality to do it justice in a single blog post so I will post a series of articles as I take the latest beta version through its paces.

  • EI Challenge #2

    EI Challenge #2

    The second biggest challenge that we encounter on all EAI projects is testing. Testing something that is essentially a magic black box with messages coming in at one end and out the other is already something of a challenge. When you add to that the fact that you are likely interfacing with multiple other systems, on multiple platforms, and using multiple protocols, you now have a huge challenge on your hands. How can you test that something that came out of SAP, came through BizTalk, got transformed, validated and encrypted, had business rules applied to it, and then was routed to be consumed by an external system actually created the expected results? How do you find out if something wasn’t quite right along the way? Where did it happen? How do you correlate the incorrect results in the target system with the actual transaction that came out of SAP and every other step in between?

    Simply put, this requires a lot of planning. Right from the requirements gathering phase, you must identify what will need to be tested and how you will validate the end results. You must also plan your architecture and design to support testing. This usually involves using some kind of transaction ID that you can use to correlate messages from source to destination. This may sound trivial, but a lot of systems do not support such an externally generated ID, and you may not have the option of changing those systems. You may have to resort to the creative use of an unused data field, or some auditing mechanism that stores both your transaction ID and the system’s corresponding ID.

    For projects of any significant size you should also plan on developing some tools to help you with the task of correlating messages and validating what happens to them (their state) at each step of the process. You should be capable of injecting and inspecting messages at all stages of the process. You should also design the system so that tracing can be turned on or off at multiple levels of detail to support various levels of testing and troubleshooting. BizTalk already offers some tools like HAT to help you with this task, but HAT doesn’t bring in data from the external processes nor does it provide a mechanism to correlate with that external data.

    In summary, testing a complex BPI solution is a challenge, but one that is not insurmountable if you plan for it ahead of time. Just like a solution architect should always wear his/her “security hat”, s/he should also wear a “testing hat” throughout the life of the project, from envisioning to deployment. Failure to properly plan, architect, and design the solution with testing in mind will result in serious difficulties and delays in the latter part of the project, and even throughout the system’s useful life.

  • DevTeach 2005

    I will be speaking on the subject of BizTalk 2004 and SOA at DevTeach 2005 in June. If you've never heard of this conference, I encourage you to check it out. It's is not only affordable, but it offers an roster of speakers, and it is set in one of the world's best cities.