TIBant™ 1.4.2 Released

We’re sorry it took a bit longer than we had hoped, but we are glad to finally release TIBant™ 1.4.2. While there are a couple of new features and defect fixes, we really want to draw attention to the new extract-properties macro, which converts existing configuration xml files to properties files that you can use with the configure-ear. So, if one of the reasons you aren’t using TIBant is because it’s too hard to migrate your existing configuration, now you have one less excuse.

A big thank you goes out to John Menzies from Think Platinum, who implemented this feature. This is our first community-implemented feature, which we think is really exciting. We don’t want to ’own’ TIBant, we want it to be a tool used by and belonging to the community. If there’s a feature you think is missing or you think should work differently, then please join in or at the very least please let us know.

TIBant™ Exits Beta with Version 1.4.0

TIBant is out of Beta! Here at Windy Road we are really happy to finally bring to you a version of TIBant that we feel is ready for prime time. We’re sure you’ll be as happy using TIBant as we are bringing it to you. But don’t think that now that it’s out of Beta we aren’t going to develop it any more. We’ve still got some more features planned and we would really like to know what features you would like to see in future TIBant releases. While your at it, let us know what your favourite TIBant feature is.

So, what’s new in TIBant 1.4.0? We’ll over here we like to call it the Validation release. Since version 1.2.1 you’ve had the to option to validate Business Works projects. Then in version 1.3.1 we added the option to validate before your build a Business Works EAR or library, but it’s always been an on or off affair. If you turned validation on and there was an error, the build would fail. But what if your project doesn’t validate, but you know it works. For instance you might be using the preceding-sibling axes, which works just fine, but the validator thinks is an error. Up until now you would have to turn of validation for the entire project and deal with the risk of invalid EARs, but not any more.

TIBant 1.4.0 allows you to specify the number of errors you expect when you validate your project. For instance, just say you use preceding-sibling in two places. You validate your project and it has two errors. You confirm the errors are from the use of preceding-sibling and you set expected-errors to 2 in the input to validate-project or validate-expected-errors to 2 in the input to build-ear or build-library. Now when the project is validated, it will pass if you have 2 errors and otherwise fail. Now you can be sure that you aren’t introducing any more validation errors.

While we were looking at validation errors, we thought we may as well look at validation warnings as well, so TIBant now has a max-warnings option for validate-project and a validate-max-warnings option for build-ear and build-library. As you can guess, it allows you to fail the build if the number of validation warnings goes above the number specified. Nice!

These aren’t the only reasons why we call it the Validation release. In the last release we added checks to really let you control and manage your Business Works global variables. Well, this time we’ve added some validation around Adapter SDK Properties as well. For those in the know, there’s a little file at <TIBCO BW Home>/lib/tibco/deployment/bwengine.xml that controls what Adapter SDK Properties can be set within an EAR. If a property you want to use is not in that file when you build your EAR, then you won’t be able to set it using AppManage (even if you add it to your configuration XML) or TIBCO Administrator. Not a nice situation to be in when you realise it hasn’t been set in production and in order to turn it on, you need to rebuild the EAR (I hope you can trace it back to the correct revision in source control) and redeploy. To avoid these types of problems, configure-ear will now fail if you have a property in your adapter-sdk-properties-refid propertyset that’s not available to set in your EAR (assuming you produced the template XML using extract-config).

On top of that we have some bug fixes for you and a new Alpha feature for you to play around with. Quite often you want to be able to produce a WSDL from a service agent. So far your options have pretty much been limited to saving it manually from within TIBCO Designer or waiting till it’s deployed and using the built in resource provider. TIBant 1.4.0 now gives you a third option, the build-wsdl-ALPHA macro. build-wsdl-ALPHA uses the existing bw-start and bw-stop macros to run the bwengine locally, so the built in resource provider can be used to retrieve the WSDL without having to deploy the engine. There’s a question about build-wsdl-ALPHA‘s implementation that we are not 100% sure about yet, which is why we are giving it an Alpha status. If you are interested in this feature, please weigh in and let us know your thoughts.

That’s pretty much it for this release, but feel free to have a peak at the full list of Closed Defects and Implemented Features.

Tame Your Business Works Global Variables with TIBant™ 1.3.2

TIBant‘s Property File to Engine Configuration Translation, has for some time allowed you to specify TIBCO Business Works engine properties (including global variables) for each of your environments in simple property files, which TIBant can translate into AppManage compatible configuration files. TIBant™ 1.3.2 comes with some great new features that will help you tighten up your control of your global variables and help prevent silly mistakes from happening.

Want to make sure that your Integer typed global variables actually get populated with an Integer? TIBant will do that. It will also type check your Boolean and Password typed global variables too.

Want to make sure that every global variable gets set, so when new global variables are added, they don’t get left pointing to Dev when you deploy to Prod? TIBant can make sure they get set. An optional flag on the configure-ear macro will cause it to fail if any of the global variables in the template XML (extracted from the EAR) are missing from the specified global variables property set. But what if you have a few global variables that are OK to leave with their original template XML values? TIBant can handle that as well and allows you to specify a property set or global variables that don’t need to be set. It even allows you to specify a property set of global variables that should never be changed from their template XML values. Cool, hey?

These new options really allow you to put up some controls around your global variable configurations, so that you find out about mistakes when you’re building your configuration, not after you’ve deployed it to Prod.

There is some more information in the release notes and even more in the TIBant User Guide, which you can download along with the binary distributions.

TIBant™ Beta 1.3.0 Released

Things are moving along quickly with TIBant and we are happy to announce that TIBant™ Beta 1.3.0 has just been released.

The 1.3.0 release brings support for Runtime and Instance Runtime Variables. Runtime variables are Global Variables that are set per Process Archive. For instance, say you had a Enterprise Archive with two process archives. Normally any Global Variable settings would apply to both Process Archives. With Runtime Variables, they can use the same Global Variable with different values. Instance Runtime Variables are a similar concept but these are set per Process Archive Instance. So, just say you had a Process Archive that uses a HTTP receiver and you would like to load balance it, but only have one machine to deploy it to. By setting appropriate Instance Runtime Variables, you can have both running on the same machine, listening on different ports. Whack a load balancer in front of them (for Services, you can use TIBCO Active Matrix Policy Manager as the proxy) and you’ve slightly increased the availability of your application.

The most relevant change for existing users, is that ant-contrib is no longer loaded automatically when you import TIBant. Instead you need to call the load-ant-contrib macro before calling any of the other TIBant macros. The example project shows how this is done.

As usual the release notes are over at Assembla.

TIBant™ is distributed under the terms of the GNU Lesser General Public License (LGPL).

TIBant™ Beta 1.2.0 Released

The Windy Road Team is very proud to announce the availability of the TIBant™ Beta 1.2.0 for immediate download.

The 1.2.0 release brings a major refactor of the interfaces for the various macros, providing consitency acrosss the entire suite. Please see the release notes for further details.

TIBant provides a set of Apace Ant macros for building and deploying TIBCO Business Works projects. Apache Ant is a software tool for automating software build processes. Ant uses XML to describe the build process and its dependencies.

TIBant features the innovative Designer Launch Control, which allows you to launch TIBCO Designer from Ant, specifing and controling your file aliases, class paths and global variables, on a project by project basis from within each project’s Apache Ant build script.

TIBant also features Property File to Engine Configuration Translation, allowing you to specify Business Works engine properties in simple property files. TIBant translates these property files into AppManage compatible configuration files, for each of your environments.

TIBant™ is distributed under the terms of the GNU Lesser General Public License (LGPL).

TIBCO’s Newest Software Partner

Today, Windy Road Technology became TIBCO‘s newest software partner. This is a massive achievement and honour for us, being such as small company. This partnership will allow us to bring to market value-add solutions to the TIBCO space, such as Windy Road BWUnit™; an innovative new tool for unit testing TIBCO ActiveMatrix BusinessWorks™ processes.