Whether it's BTS04 or 06 - you can always generate the schema behind the magical binding file from the following command (courtesy of Mark Berry):

xsd.exe "C:\Program Files\Microsoft BizTalk Server 2006/Microsoft.BizTalk.Deployment.dll" /type:BindingInfo

-Mark Berry

Pretty cool - thanks Mark. (obviously change '2006' to '2004' if on BTS 2004)

You now have an XSD that corresponds to all the options in your Binding File.

Enjoy!

We've got a decent PDF IFilter from found on the MS IFilter Blog.

The IFilter team have been busy and while this IFilter is by a third party, I believe it has under gone some internal MS testing.

One of the things I've had trouble with in the past has been Native Adobe Compression within PDFs. In the later versions of PDF writer/distiller etc. when outputting a PDF, one of the options is to select the amount of compression (a slider bar from memory).

I was onsite and noticed that out of the 400 PDFs in our 'test' folder, around 50 were not being properly indexed (only filename, filesize, location etc were 'extracted').

All of these 50 documents had PDF compression set to 'high' (there were 4 different compression settings)

You may or may not have to add the work around below - Foxit have updater their installer.

---- snip ------

Long awaited 64-bit PDF IFilter finally available.

Finally we have a 64 bit PDF IFilter - surprisingly the solution is not from Adobe or Microsoft, but from a company called Foxit Software.The IFilter is compatiable with the following Microsoft products: Windows Indexing Service, MSN Desktop Search, Internet Information Server, SharePoint Portal Server, Windows SharePoint Services (WSS), Site Server, Exchange Server, SQL Server and all other products based on Microsoft Search technology.

 There's one simple workaround to get the filter running on 64 bit MOSS 2007. The steps are given below.

1. Install Foxit 64bit PDF Ifilter. http://www.foxitsoftware.com/pdf/ifilter/

2. Add a pdf extension in MOSS search settings

3. Open regedit, locate [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]

4. Change the default value to {987f8d1a-26e6-4554-b007-6b20e2680632} .

5. Recycle the search service: net stop osearch
                                              net start osearch

6. Start a full crawl to index your pdf documents :)

Years ago we struggled when clients surfed to web pages, to try and get any sort of information out about them.

To get more info, we would present a little page with some client script to determine ('mine' being the operative word) their capabilities (cookes, script, even had access to Navigation History etc etc)

I was recently contacted by a site and part of the request I was presented with my User_Agent string for my initial request.

HTTP_USER_AGENT=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; Tablet PC 2.0; InfoPath.2; FDM)

Who can determine the most out about this machine?

So your default User Agent strings *do* tell alot about the software you're running. We can modify this, but you run the risk of websites etc. not interacting fully with you (and I know how much we all love our Ajax!)

Over the times parents have named their kids many things...but I do feel sorry for this little girl being called Vista.

A father called his daughter Vista....does this mean the son will be called 'LongHorn' and who knows about upgrades, boyfriends and remote offsite camping trips.

Wonder no more why so many people change their names over in the US.

Monday's tidbit.

MOSS and reporting services integration......

After installing SQL2005 SP2 and SharepointRS.msi (Sharepoint 'extensions') you're left to do a 'small' amount of configuration. Basically telling the MOSS environment where to find the Reporting Services Server.

Previously this has been a difficult step - almost a journey of discovery. Here's the answer.

From Central Admin->Web Application->Reporting Services Configuration Integration

From below the 1st box always gives grief - the label title and the description seem to indicate different things.

So just to put this to bed - the Web that you have ReportingServices installed - point off to the ReportService WebService - you're good to go!

Wow what a night planned!!! WF 101 (even good for managers! :)); BTS hosting WF and making it all happen under BizTalk Labs (that's next after R2)

Check it out and looking forward in seeing you there......

-------- Details ---------

Examine Windows Workflow talking to BizTalk R2 and BizTalk Labs.

Firstly a BIG thanks to those that enjoyed the exam cram we did last month (we had to order additional pizza!) and I’ve since heard that several of you have sat and passed the EXAM!!! Well done!!

With R2 just around the corner......I decided to tackle the Windows Workflow(WF) question.
The message is usually BTS vs WF, never BTS AND WF.

We’ll cover:

1.      Workflow 101 (you should be able to bring your manager along to this one J)

2.      Hosting Workflow’s within BizTalk with the new BizTalk extensions for WF SDK

3.      BizTalk Labs – life after R2....and where we are heading.....

Meeting details:

When: July 4th Food at 6pm, kick off 6.30pm. Finish up around 8pm.
Where: Microsoft
1 Epping Road
Riverside Corporate Park
North Ryde NSW 2113 Australia. (parking available)

WF Session Focus Details:
1.First up we will look at the fundamentals of Workflow; what makes them run; communications; and how do we host them.
(WF is the technology that is brightly coloured in VS.NET and comes with .NET 3.0) – you could even workflow your toaster if you wanted to.

2.Next – we’ll take a Workflow and use WCF under the covers to act as the communication medium between BTS R2 & WF. Very nice.
So now in BTS R2 we can host WF (through a small ‘Orchestration wrapper’) meaning that when BTS persists, WF does too – WF is now running inside BTSNTSvc.exe.
(cross off the list – ‘find a place for my WF’s to live’)

3.Thirdly – Imagine being able to call our creation from anywhere and behind umpteen firewalls between caller/sender.....enter into the ring
BizTalk Labs!!! Very exciting – labs.BizTalk.net.
(what communications do you think we use.......WCF......hmmm....seems to be a common thread here!)
So it’s a night on WF/R2 wrapped up in WCF – wow what a great set of technologies!!!!

See you there and let me know your coming
Mick Badran.
p.s. I’ve fallen in love with Microsoft Surface.......wow!!!

What a name....talk about the pinnacle of TLA's at the height of a great technology field.
Can you imagine being at work/meetings etc.
and say "Hold on, I've got to grab the WCF LOB Adapter SDK for my BTS Messaging Hub"
(at this point I'm sure it would clear the floor if you were at a party and people would be looking at each other thinking that someone hasn't taken their vitamin B12 this morning)

So we really do need to come up with a sexier name than this (when I was 4 my parents read me a great book about a kid called "Tikki-tikki-tembo-no-sarembo" and he fell into the well - you could say I was scared off long names as a kid)

What does this thing do for you? It will change the way you develop adapter for use with/without BTS. Sensational!!!

WCF LOB Adapter SDK

Enjoy!!!!

p.s. you don't necessarily need BizTalk to build adapters with this framework. There are BTS06 R2 'extensions' to this framework - the BTS 'strand' of this SDK is currently called the BizTalk .NET Adapter SDK

There's some very cool things ahead.....stay tuned......

MS have been busy in this space and we've now got the following (or soon will have :)

1. BizTalk Server 2006 R2 Evaluation Edition
2. BizTalk Server 2006 R2 Branch Edition
3. BizTalk Server 2006 R2 Developer Edition
4. BizTalk Server 2006 R2 Standard Edition
5. BizTalk Server 2006 R2 Enterprise Edition

Most are pretty self explanitory except for the Branch Edition (BE) - for those of you that remember the BTS Partner Edition (phased out with the introduction of BTS2006), BE is comparable with it.

There are some restrictions on this though (as currently determined by the powers to be...):
- the BE must connected to Enterprise Edition.
- two or more BE's can't talk directly to each other, must go through a Enterprise Edition

There's a document available that discusses upgrading to BTS06R2 - it's still a work in progress but it's a good start -
MS Upgrade Document

In particular there is a great image that gives a good outline of the dependencies (taken from the document):

Food for thought folks - there's some very exciting times ahead.

Finally it's here - there was some talk internally within MS about an adapter being built to communicate to WF Runtime, thus allowing hosting of WF workflows within BizTalk.

At the moment we're at cross roads with BizTalk 2006, as the Orchestration/Business Process designers and technologies is built on a language called XLANG which is compiled into C# and executed.

On the other side, we have WF workflows, XAML, XML, .NET based, extensible and looking good.....but it needs to find a home. It's homeless but always keen to meet up with a host. The question of hosting WF Workflows is not taken lightly as scalability, availability, durability etc all come into the equation (the 'hello world' WF console application just doesnt cut it :) )

So let's get the best of both worlds - I previously did a MSDN webcast on this around the time when the message from MS was "for small stuff - use WF. For bigger things use BTS" - but why cant the 2 worlds live together?

Now - they can!!!!

Microsoft WF Team have released 'BTS Extension for WF' where there is 'no BizTalk code required' (hmmm....maybe I should stop my mission of finding BizTalk people and look at WF people).

Go and register on the connect site/fill in a quick survey and get downloading!!!!

Grab the BTS Extensions for WF here

Happy playing........it's wabbit season...no duck season....no wabbit season....

I'll post more details very soon, but for this session

I will be covering

Windows Workflow Foundation (WF) - 101 basics all you need to know

BizTalk meet Workflow, Workflow meet BizTalk - Hosting WF Workflows within BizTalk 2006 R2!!! (how good is that!!!)
(persistence/tracking etc etc all taken care of - a wizard comes to the rescue)

Stay tuned for a full update.

July 6th 4TH is our next meeting (I had to move it till next Wednesday) (thanks Bill)

It's great to see, for some time now I've been a huge advocate of how BizTalk and WF *can* work together.

In the past the message that has been sent by MS has been an either/or message - never together. (e.g. small things WF....enterprise SAP/Siebel etc. = BizTalk)

Well my good friend Paul Andrew is all over this with the release of a BTS WF Host Tool that:

1. Takes a WF Workflow

2. WCF is used for the underlying communications between BTS and WF - seeing that BTS06 R2 is now WCF capable, it's a perfect synergy!!

3. WCF Message Contracts defined in the WF Workflow

4. The tool runs over the WF workflow to produce the 'stub/proxy' Wrapper Orchestration so that (and this is the most exciting piece of news) BizTalk will serialise the idle executing Workflows when needed AND the wrapper orchestration automatically handles all the correlation to locate the appropriate WF within the WF Runtime, via a WF Host class called _WFHost (also automagically generated)

For me the most exciting thing is that - now you dont need to write wrapper Orchestrations etc. and do a bunch of work within BizTalk to get the communications to happen.

We can use CBR to route to our Workflows etc.....very very coool

Available to the public BY THE END OF THIS MONTH :)

------------------ FROM PAUL ANDREW's BLOG -------------------------
(bless his cotton socks :)

BizTalk Adapter for Windows Workflow Foundation sample (June 2007 CTP)

Just announced today at TechEd 2007 in Orlando Florida. We are developing a new SDK Sample that lets software developers build workflow models in Windows Workflow Foundation and then host then in BizTalk Server 2006.

The BizTalk Adapter for Windows Workflow Foundation SDK Sample (June 2007 CTP) is a preview of some new technology for business logic and process developers. It provides for workflow models developed using Windows Workflow Foundation from the .NET Framework 3.0 to be hosted in BizTalk Server 2006. By doing this the workflow gains access to services from BizTalk Server 2006 including scalability, reliability, manageability, and access to messaging with BizTalk Server ports. The next major version of BizTalk Server is planned to be built on Windows Workflow Foundation and this CTP provides an option for customers to do this with current technologies. A release date has not yet been planned and will depend on customer feedback and the sample is currently not planned to be Microsoft supported. The CTP is suitable for software developers familiar with Windows Workflow Foundation and is provided as an SDK sample with source code.

The sample provides a tool that evaluates an existing WF workflow model and creates a BizTalk orchestration project as a proxy for that WF workflow model. The orchestration can then be deployed to BizTalk Server and the WF model is used.

Watch a Demo Video

Jon Flanders has recorded a 45 minute video demo of using the CTP to host a WF workflow model in BizTalk Server 2006 and he shows it running. Watch here.

Sometimes when you have a published WCF Service, you may just want to allow that service to provide a description about itself - rather than go through yet another wizard (re-run the WCF Publishing wizard) to expose out some metadata.

I've been doing alot of R2 lately and this exact problem came up. Fortunately I found a quick and easy way.

Simply add the following lines to your Web.Config before the </Configuration> tag
(take it out when you're finished)

<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehaviorConfiguration">
<serviceDebug httpHelpPageEnabled="true" httpsHelpPageEnabled="false" includeExceptionDetailInFaults="false" />
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<!-- Note: the service name must match the configuration name for the service implementation. -->
<service name="Microsoft.BizTalk.Adapter.Wcf.Runtime.BizTalkServiceInstance" behaviorConfiguration="ServiceBehaviorConfiguration">
<endpoint name="HttpMexEndpoint" address="mex" binding="mexHttpBinding" bindingConfiguration="" contract="IMetadataExchange" />
<!--<endpoint name="HttpsMexEndpoint" address="mex" binding="mexHttpsBinding" bindingConfiguration="" contract="IMetadataExchange" />-->
</service>
</services>
</system.serviceModel>

It doesn't get easier - enjoy!

Currently I'm setting up a system and found an interesting 'challenge'. After some sweat and tears I stumbled upon this Microsoft article.

In the article it appears that running IIS 6.0 on a 64-bit box is cool. (obviously or there'd be trouble)

It's also cool to run 32-bit ASP.NET apps in 1.1/2.0

It is not cool to run a mix of 32- and 64-bit in the same IIS.

Thought I'd save you my pain!

I could talk about it........I soooo wouldnt do it justice........forget the pacman cocktail machine.

See MS Surface

Here’s a Microsoft Surface demo:

Sensational Sonu has a great article on her blog about how we develop custom WCF Adapters for use with BizTalk R2.

She mentions:

1. BizTalk will always call the Adapter custom channel via a 'Request/Response' mechanism - this means for:

• Custom WCF Send Adapters - BTS will *always* call IRequestChannel (two-way) (WCF also supports IOutputChannel - oneway)
• Custom WCF Receive Adapters - BTS will *always* call IReplyChannel(two way) (WCF also supports IInputChannel - oneway)

So in short - BTS will always call a 'two-way' method of a custom WCF Adapter.

In terms of 'Fire and Forget' one way WCF Services, we still need to call the Two-Way interface and just pass back a null response message.

Or you could use your own custom component - said like a true developer!

Cheers,

Mick.