Wednesday, January 05, 2005
Ever wanted to quickly and easily try out different XPath expressions on your documents?
Just click this link!
Tuesday, January 24, 2006
Today's tip is brought to you via the BizTalk 2006 Deep Dive training course that I'm on, run by Alan Smith of the Bloggers' Guide to BizTalk fame..
In BizTalk 2004, if you wanted to create an empty output element in your target document via the mapper, you had a couple of options. You could either use a string concat functoid with one empty input parameter, or use a value mapper with 'true' and an empty string as its inputs. Bit tacky really, and in the case of a string concat also a bit slow as it uses inline C#.
Well rejoice, for in BizTalk 2006 there's a new drop-down option on the "Value" field of the mapper that lets you pick "".
Lovely! Especially handy if you are using the little-known but amazingly handy Property Demotion technique to populate message fields on the way out.
Incidentally, further to the system context properties described in the link above, you can also demote your own promoted properties from your own custom schema back into your message in the send pipeline.
Flat file parsing in BTS2006 is pretty nice in general - you get a very specific error back in the error log if your incoming file is in the wrong format for the schema (or, put a more likely way, if you have buggered up creating the schema).
However, this vague error stumped us for a little while:
There was a failure executing the receive pipeline: "Orders.ContoFFPipeline.ContoFF, Orders.ContoFFPipeline, Version=1.0.0.0, Culture=neutral, PublicKeyToken=d5d6f7acdeb815af" Source: "Flat file disassembler" Receive Port: "RcvEnvelopedDocument" URI: "C:\FFIN\*.TXT" Reason: Unrecognized data in remaining stream
In our case this was due to a rogue carriage return at the end of the file (we had two instead of one!). Hope this saves someone some time!
Here's a braindump that I did for people with 2004 experience who are moving across to 2006. It's just a very quick run through some of the new bits and pieces to look out for. It's not complete, but it might be handy as the 50,000 ft view. It's also written with a dev audience in mind and is not necessarily the view of my employer either! (Is that enough caveats?).
New Features
Functionally very smilar to 2k4 - nothing like the shift in experience from 2k2 to 2k4. It's a "tidying up/more functionality" release, not a re-write.
The #1 new feature: You can zoom orchestrations in the development environment ;-)
New BTS Admin tool which is actually useful (cf current admin console) and can be used to make modifications to your server. Also contains really good reporting, far nicer than HAT, for investigating failed messages.
New security group aimed at system operators who need to maintain, not modify, a server install
Includes lots and lots more adapters out of the box - eg MSMQ, POP3. Also all the iWay adapters such as JD Edwards, out of the box.
Really nice flat-file schema wizard, should save hours for anyone who needs to work with flat files.
Solution Deployment
Really, really, really, really nice. Collections of assemblies/bindings/resource files/etc are grouped into "Applications" within BTS. These applications appear as their own controllable group within server administrator. You can start and stop the whole thing (including orchs, send/receive ports) simply with a right click. You can also right-click and generate an MSI ready for import to another BTS2k6 box - and yes
you can include multiple bindings files for multiple environments and it prompts you at MSI import time as to which environment you are setting up. Interesting to see how
Scott Colestock makes use of this.
Server Installation
This is now much easier. All pre-requisites are supplied in a CAB file and installed for you, so no more hunting around for Patch A and Service Pack B.
Install is a two phase process: 1 - Install 2 - Configure so you can install to multiple boxes, then just run the configuration wizard to set up multiple identically configured BizTalk boxes. Config tool is now robust and usable (cf ConfigFramework.exe)
You can install on XP - but don't, as you get a slightly different feature set and the install is slightly different. Better to stick to 2k3, unless your client's servers will be running XP of course ;-)
You can pre-create BTS Databases and the installer will use them and configure them. Just create an empty DB with the right name, and off you go. This is good for live deployments where you can create the database on teh server and disks that you want, precreate to a sensible size instead of forcing it to autogrow up to 2-3GB - a good way to boost performance.
Apparently, renaming of a biztalk server will be supported using a UI. This has yet to make an appearance in beta though.
Migration
BTS2004 projects "will" open fine in 2006. There have been reports of one single schema file that had issues, but it took 5 minutes to fix.
BAM
New BAM portal, which runs on ASP.NET. BAM can now hook into pipelines and message properties, not just orchestrations, so you can use it for pure messaging solutions too out of the box without dropping down into custom pipelines, custom components and the BAM API.
Can maybe use BAM for large-scale message tracking instead of TPE, with potential big performance gains as you get a dedicated database for it. This is just an idea some people are floating at the moment, and worth looking into for advantages/disadvantages
Samples
BTS2k6 ships with "Scenarios" - showing, eg, b2b, messaging, and so on. These are enterprise quality, complex applications showing best practice. Significant dev effort from MS into making these, so leverage them. Also probably contain useful components and utilities.
Random
Apparently XBox Live runs on BizTalk 2006 :)
Tuesday, January 10, 2006
Well, Owen has been bugging me to blog... so just to keep him quiet, here's something random...
If you want to hook up on the XBox 360 then here's my Gamercard!
Monday, April 26, 2004
StrokeIt is a fantastic piece of software that I just found: It allows mouse gestures in all of your Windows applications. It's free for individual use, and a bargain $10 for use in corporate settings (
details).
If you've never tried Mouse Gestures, you are really missing out. Essentially you hold down the right mouse button, draw a shape on screen, and "some action" happens depending on how you configure it.
It's great for UI-intensive tasks, such as designing orchestrations or web browsing, as you can quickly and easily close windows/run explorer and so on without needing to either aim at small screen icons or have a hand permanently at the keyboard, freeing it up for other handy things such as holding a cup of tea while you work.
Current favourite gesture (I could make this a feature?) are drawing "E" for explorer and "C" for close window :-)
Download it now!
Tuesday, May 04, 2004
I've noticed a number of referrals from Google from people looking for help with the UI Process block.
Having spent some time with the UI Process Block I'd like to share my experiences, but to do that I would like to know what information people are after. Please leave me a comment below, or contact me directly using the "Contact" link above and I'll try to come up with some suitable articles.
Finally the obligatory plug: If you are looking for help with UI Process Block implementation, especially on projects that also involve BizTalk, my employer (www.solidsoft.com) specialises in BizTalk and .NET implementations so feel free to make an approach to learn more about us and (I hope) engage us commercially.
IMPORTANT UPDATE: I haven't worked with the UI Process Block for almost a year, so it's increasingly hard to devote time to looking into these issues. Please feel free to continue using my comments section to ask questions - but it's unlikely that I'll be able to chip in with answers. Don't forget the Got Dot Net workspace.
IMPORTANT UPDATE #2: I've now closed comments on this entry; please direct your questions to the official Got Dot Net workspace.
IMPORTANT UPDATE #3 :): Closing comments meant they weren't displayed any more; that was unintentional and seems to be a limitation of the .Text blog engine. Comments are open again so that you can see the old content :).
Tuesday, January 18, 2005
Owen Cutajar blogged about "The 5 biggest mistakes almost all web designers make".
I'd like to add a site to the list... I recently tried to browse this page on the Sony Connect Website from a Windows 2003 PC, only to be informed that:
We appreciate your interest in the Connect music store, but our store currently only works with computers running Windows 98 Second Edition or higher. [...] We'll have to part ways until we support the operating system you're currently using, or you make the switch to an OS that is compatible with the Connect music store.
Unbelievable. So they think it's ok to require customers to change OS just to browse their site? I guess that's one potential customer they've lost. Oh well, if I ever downgrade back to Windows 98 I may go back!
(As an aside - if anyone has an alternative source for the MSNBC Tsunami Aid concert, that would be great, since MSNBC Europe showed a programme about stocks and shares instead of the advertised show!)
Tuesday, January 11, 2005
The Solidsoft blogging community continues to grow! My colleague Richard Case has just started his blog. I know recently he's been doing some cool stuff with NAnt tasks for BizTalk deployment that have a lot of synergy with Scott Colestock's work and luckily don't overlap it too much, so check out his blog...
Monday, December 13, 2004
A couple of blog entries that I wanted to highlight, but I've been a bit late blogging on (blame short-sharp-"just do this project before Christmas would you?" type work).
First, I'm sure you've all seen it by now, but Scott Colestock is continuing his barnstorming work on BizTalk deployment with NAnt. Check it out. BAT files are so 1980's ;-) If you're not doing something similar in your deployments (either through your own work, or using Scott's) then you are really missing a trick.
Also, a big plug must go to Thinktecture's new release of WSCF (WsContractFirst). As soon as I get two minutes to breathe (i.e. after Xmas), I'll take a proper look at this, but for now it looks pretty good.
Friday, December 10, 2004
A few days ago, I blogged about splitting documents.
It seems that there's a bug in BizTalk that means this approach won't work. The typical pattern when defining an envelope schema is to define your repeating node as one schema, and xs:import it to your envelope schema (for details, see Jan Tielen's excellent blog entry).
Unfortunately, if you create a map that maps to your envelope schema (for example in my case because the envelope schema is also the canonical batched data format), then that map is unable to execute in a receive port (and presumably a send port, although I haven't checked). When a document is received, you will get the following error logged in the Application log:
Document type "uri:my-uri#Customer" does not match any of the given schemas.
(where uri:my-uri#Customer is the root node of the xs:imported schema).
Hugo Rodger-Brown also ran into this at the same time as me so we're both left scratching our heads.
I can't help feeling that this is somehow related to Scott Colestock's old post where he notes that, unless you have a fully qualified assembly name, a pipeline will fail to load your schema because BTS simply doesn't know which assembly to search for the type.
Obviously, receive port maps are run after the pipeline, but I still feel it's all relating to the same kind of issue. If you open up the source of a .btm file, you'll see that the node only references the type of the destination schema - it doesn't use a fully qualified name. Unfortunately, editing the map source to use a FQN won't work (the mapper shows an error in the designer).
So, in summary it looks like you simply can't map to a schema that references other schema from within a receive (& send?) port. Note that it works fine from within an Orchestration - probably because the Orchestration has a reference to the correct assembly, and so it can resolve the type name successfully.
Monday, December 06, 2004
An interesting scenario came up this afternoon. I receive a bunch of different documents containing address changes, which I map to my canonical "address changes" format in the receive port. I then want to split my canonical document using an envelope so that each address change record is out on its own.
As far as I can see, to do this I'm going to have to write the canonicalised document out to disk, then read it back in from disk and split it in the corresponding receive pipeline. This feels awfully inefficient, but luckily it's only for a demo system.
I know that the messagebox allows for far more sophisticated subscriptions than are exposed through the User Interface, and obviously orchestrations can subscribe based just on document type, but does anyone know of an equivalent to "The Messagebox" as a receive location transport type?
On a side note, the lack of blogging recently is entirely down to being on holiday, and an addiction to Halo 2 on XBox Live :-) If anyone fancies a game, invite me over to your party - the gamertag is "shelfsider". I'm varying between level 3 and 5 depending on the gamemode, so not too tough an opponent!
Update
Thanks to my colleague Charles and to Berneba (via comments) for the suggestion of using a loopback adapter. In this case it's probably not going to work as I'm trying to split the document and it's not clear what I'd receive back into the orchestration.
For the purposes of the demo system I'll stick with taking a hop onto the disk, but Darren Jefford's post about looping gives some good ideas - particularly using the little known xpath function.
Tuesday, November 09, 2004
I've held off posting on the WSDL-first approach so far because I've been waiting for the tools to arrive to make my gripes go away. Well, I'm still waiting... and waiting...
In the BizTalk world, we already have a Service Oriented mindset. We communicate in terms of schema-defined documents; we offer up services not APIs. We want to be interoperable with as many people as possible. I don't care whether you're using Java, .NET or ARM assembler - if you can send me a soap message, I'll talk to you. The trouble is that the .NET world approaches web services from a very object-y view point. Just pop a [WebMethod] in your asmx page and let ASP.NET create you some WSDL describing your objects. Easy, right, for people who want to knock up a quick web service in code?
The trouble is this promotes a very code-first approach. This really sucks from a BizTalk developer's point of view. I already have my schemas. I know the shape of the messages I want to receive. Where's the support for the Schema- and WSDL-first approach? The "publish orchestration" wizard seems ropey - a colleague today ended up with unusable WSDL just because he'd used an xs:import in his schema. Besides, I don't want a "publish orchestration" wizard, I want a WSDL designer with "create BizTalk orchestration template" and "import BizTalk definitions" options.
How about BizTalk's support for consuming web services? If I add a reference to a Web Service, I want the types defined in that WSDL added as first-class schemas in my BizTalk solution, not hidden under MyWebReference\Reference1.xsd. I want support for promoting properties out of the web reference - just remembering them if I refresh the web reference would be nice. Even worse, if I already have those schemas included in my solution please don't create a duplicate copy of the schema - share the reference (.NET 2.0 has an enhancement to WSDL.exe that may support this, I believe).
For the record, I am very much in favour of WSDL first. I just think there's an awful lot of pain to get it working in anything but the most simple cases. Let's hope Microsoft's new Domain Specific Languages designers lead to some WSDL designers pronto. XML Spy looks nice, but it's damned expensive!
This hasn't been a very structured post, for which I apologise, but I'd love to hear from anyone else who has found any silver bullets for BizTalk and WSDL-first...
Monday, November 08, 2004
Things I like to see in my MSN window #1:
"Can you get up to TVP? Halo 2 team are here and we're playing."
WOOHOO! Just had a 6 minute deathmatch round against the UK XBox team. We lost about 50-20, which is pretty shabby, but I did manage to score a double kill. Dual wielding SMGs is teh roxx0rs! I just about resisted temptation to hit campaign mode ;-)
Roll on Thursday.
Wednesday, November 03, 2004
I was chatting to my colleague Charles Young earlier today and it reminded me of an idea that I had a while back. Wouldn't it be nice if, instead of having expression shapes (and the awful expression editor window ;-) ), we instead had an ASP.NET-like "code behind" model allowing us to use any .NET language, and not have to worry about working within the restrictions of XLANG/s. Of course I appreciate the design principle that Orchestrations shouldn't be littered with code and you should instead be calling out to .NET classes to do the real work, but the developer experience of ASP.NET code-behind development is just so appealing. Orchestrations are rather like ASP 1 for calling code in their current form.
That led me to thinking that effectively you'd have anonymous blocks of code (a la .NET 2.0) subscribing to certain events in the orchestration; following that thought, if you could create subscriptions for blocks of code, you'd be opening up a whole world of possibilities (or, maybe, pain). Then again, that's not such a big step from the Aspect Oriented ethos - Aspect Oriented Biztalk anyone? ;-)