This week I had the first real use case for embedding a script inside an adapter workflow. In one particular instance we were actually receiving EDI files that were terminated by an odd character; od and hexdump thought it was \0205 (0x85) but when we read the file in using a java test stub it turned out to be 0xffffff85 which was annoying to say the least.
We can turn it into 0x85 by doing a classic & 0xFF, but you can’t do that terribly easily within the adapter, so this is a perfect chance for us to use [jruby]!
Setting up the adapter for multiple ways of handling errors
As we all know error handling within the adapter can be configured at the workflow, channel or adapter level. Most of the time we just write the original file out to something that can’t fail (well, unlikely to fail in the context of things) like the file system.
You care about being compliant with various regulatory regimes that say you can’t ever remember private 172.16.x.x IP addresses and say them out loud (or write them down); and yet they will happily use Winzip to password protect a zip file with an easy to remember password (sometimes to maintain “compatibility” they use encryption that can be extracted by earlier versions).
If you’re like me then perhaps you often don’t want your network interfaces to be enabled all the time. You might not have a hardware switch to turn off your wireless and going to Network and Sharing -> Change Adapter Settings right click enable / disable seems like such a chore especially when my default group policy means that you’re prompted for your password each time.
Well, the windows scripting host is your friend; here’s how to toggle your network interfaces
Making VMPlayer Network interfaces part of the private network
One of the things that you’ll find with VMPlayer is that the network interfaces aren’t registered properly with Windows (Vista or 7) which means that you’re always in the Public zone, so your firewall is always turned on (that’s right, you have a firewall don’t you).