by community-syndication | Mar 21, 2006 | BizTalk Community Blogs via Syndication
Last year I documented growth in the server market for office based systems, especially the google initiative, and via this blog I questioned Microsoft’s Office Staretegy? Well they have answered …
Its interesting to see that the next version of anticipated office server products such as excel, infopath and possibly others such as visio, have been packaged up together under the Office Sharepoint 2007 brand.
More details can be found here from Microsoft Press
http://www.microsoft.com/presspass/press/2006/feb06/02-15OfficeMoreOptionsPR.mspx
Join this session to understand new Enterprise Content Management is feautured
http://www.aiimexpo.com/aiimexpo2006/v42/conference/session.cvn?eID=81
Have a look at these sessions to see Windows Workflow Integration with Sharepoint Services 3.0
http://www.microsoft.com/belux/nl/devitprodays/agenda/sessions1.aspx
Sharepoint Services 3.0 Documentation is here
http://www.wssdemo.com/blog/Log/DisplayLog.aspx?ID=148
Finally for further insight into Sharepoint Designer 2007 look here
http://www.microsoft.com/presspass/features/2006/feb06/02-15Designer.mspx
And finally for something groovy look here
http://www.groove.net/home/index.cfm
by stephen-w-thomas | Mar 21, 2006 | Downloads
This tool can help with importing and exporting policies and vocabularies in BizTalk Server 2004. This tool supports the use of a configuration file to limit what is imported and exported. This should also work for BizTalk 2006.
Get more information from the original blog post on this topic: https://www.biztalkgurus.com/blogs/biztalk/archive/2006/03/21/BizTalk-Server-2004-Rules-Engine-Deployment-Tool.aspx
by stephen-w-thomas | Mar 20, 2006 | Stephen's BizTalk and Integration Blog
Find yourself running the Rules Engine Deployment Wizard over and over again to export and import policies and vocabularies? Looking for a simple push button approach to move a full configuration from one server to another? My simple Rules Engine Deployment Tool will help with these common tasks.
This tool will do the following:
- Export all your policies and vocabularies
- Export your most recent policies with dependant vocabularies
- Export policies based on a configuration file with dependant vocabularies
- Import all policies and vocabularies in the Import folder
- Import polices and vocabularies based on a configuration file
Download: BizTalk Rules Engine Deployment Tool
How to use this tool:
Simply extract to your C drive, build, and run it. Vocabularies that reference other vocabularies are not really supported. That is, you will have to name the files so that the most referenced vocabulary is imported first or use a configuration file. Also note that the process is not transactional. So, if something fails the import will stop in the middle. I have included some sample policies, vocabularies, and a configuration file so you can see how to use them.
The main purpose of this tool is to move one full set of rules from one server to another server although using the configuration file you can do just about anything you like.
I have not tested this with BizTalk 2006, but I would guess it would work.
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
Way to go, Scott. On May 6th, Scott is going to be walking to fight diabetes with Team Hanselman. The goal is to raise $10,000 for the cause. If you want to learn more, or learn how you might help, see Scott’s post:
Team Hanselman and Diabetes Walk 2006
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
Hi,
This is yet another long awaited “project” that I’ve been working on behind the scenes, the exponential improvement of the DSL Tools over the last year has meant I’ve had to throw away more and more code which is a great story for how compelling the DSL Tools can be, plus Team Foundation has only just shipped so the potential audience for such a tool has been pretty limited.
For those of you not in the know, The Domain Specific Languages (DSL) technology from Microsoft which is currently in Beta allows you to define a Domain language and then develop a graphical designer with next to no code. The designers are built on the same platform as the “Whitehorse” designers shipped in Visual Studio Team Architecture so you can acheive the same look and feel.
As you may or may not know, Team Foundation Server has a concept of Work Items. These Work Items can be bugs, tasks, requirements, or anything you like – they are rendered as “forms” inside Visual Studio 2005 Team Explorer or the Team Foundation Client to track, create and modify Work Items.
Microsoft Project and Excel can also be used to manage these Work Items and the programmability interface is exposed via a .NET API and a Web Service meaning third-parties can also provide tooling.
Team System ships with the following Work Item Type definitions out-of-the-box and they will be available dependent on the Process Methodology that you select when creating your Team Project: Bug, Task, Requirement, Quality of Service Requirement, Risk and Scenario.
Quite often customers will be happy to use these Work Item Type, but more often than not you may not like the terms we use such as Iteration, Milestone, etc. and you can change the names of any of the items on these Work Item Type definitions and if you want to collect further information you can add your own fields.
In Team Foundation V1, there is no graphical tool to customise these work items so you’ll need to use your favourite XML editor (normally notepad!) to customise the work item XML. The Work Item XML document is fairly complex and has lots of intra-dependencies so you have to be sure to get the spelling of everything right for example.
Within a Work Item Type definition you essentially have a Workflow, you have a set of possible states that a Work Item Type can go through (Active, Resolved and Closed for example) along with possible State Transitions that can occur (i.e. you can go between Active->Resolve, Resolved->Closed, Closed->Active but not Active->Closed).
This type of workflow is very hard to visualize in an XML document which is where the VSTS Work Item Type designer comes in, I reference such a designer in my DSL Tools Chapter which is part of the Professional Visual Studio Team System book – it includes a screenshot of an early version of the designer.
The designer leverages DSL Tools and Visual Studio 2005, a Domain Specific Language model has been defined based on the Work Item Type Definition language and a graphical modelling tool has been overlaid on top, apart from defining the language model which is pretty straight forward the only real code I’ve had to write is to load the XML up into a serializable class and map to the domain model and vice versa which is a compelling story for the use of DSL Tools.
The current domain model is shown below:
The designer presents a graphical view of a Work Item Type definition, States are shown with connectors representing the allowed State Transitions between and Fields directly used in State Transition validation are depicted directly on the State. The Work Item Type Explorer pane shows the language model in its entirety including all of the available fields (not all fields have to be used by State Transitions).
The Toolbox on the right hand side lets you drag new States and create new State Transitions between them, new fields can be added by right clicking the Fields node in the Work Item Type Explorer. Properties of all these elements are shown in the properties pane as you’d expect.
Here is a sample designer screenshot (click for a larger image, if it looks wierd ensure IE hasn’t shrunk the image by hovering over and clicking the expand icon that appears in the bottom right)
I’m currently porting a pretty-fully featured version of this designer across to the latest drops of the DSL Tools, most of the porting involves throwing a lot of code away as the more recent builds do so much, and tidying up fairly hacky bits of code that I threw together before a product team demo.
Within the Work Item Type definition there is a notion of form layout, this is used when displaying a form to the user, this is really hard to display and doesn’t lend itself to a DSL Tools Designer, hosting the Windows Forms Editor (if that’s possible) would be the better option. So layout is ignored as part of the designer but any layout already specified in the file remains (I only update the sections that can be visualized) and for new fields I insert default form layout markup which you can then change by hand.
If your interested in trying the designer out then I’ve uploaded a current release of the designer to a new GotDotNet workspace. This release works with VS2005 and it will install the DSL Tools Redist as required, you’ll also need to download the latest VS SDK (free once you’ve registered) as I haven’t got a Package Load key for VS2005 yet to enable it to load in a regular install of VS2005 (I have to jump through some hoops internally to get this done).
This release lets you open a Work Item Type definition that you’ve exported from Team System or created yourself and visualize it, you can add new States and Transitions, and new Fields (by right clicking Fields in the Model Explorer).
I’ve temporarily disabled the Save feature as I’m not currently able to ensure everything in the original file is serialized out correctly (i.e. you might get a bit of data loss) – I need to ensure that all elements of Fields, States, etc. are represented in the domain model before re-enabling this.
Hopefully this gives you a taste and I’ll look to get a more complete build up in a few weeks, let me know how you get on with it!
I’ve provided a sample Work Item Type extracted from a live Team Foundation Server, if you want to extract your own from an existing Team Foundation server you can do so using the witexport.exe tool that you can find in the %PROGRAMFILES%\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies folder.
witexport / <outputfilename.wit> /t <TeamFoundationServerName> /p <TeamProjectName> /n <Work Item Type Name>
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
Visual Studio 2005 added support for Debugger Visualizers. With debugger visualizers, developers can define what information (and in what form) is shown in the debugger for a specific type. There are many visualizers for various .NET types floating around. Here is a small list of the most popular ones: ASP.NET Cache, Regular Expression, XmlDocument (and other Xml related types), a powerful looking DataSet visualizer and there is even a WindowsIdentity visualizer.
I am not going to explain in details how to write your own visualizer. You can find step by step instructions on MSDN. Most existing debugger visualizers I mentionned in the previous paragraph also have home pages where you will find details on how to write your own or even source code.
I’d like to share some tricks you might find useful when writing your own visualizers:
- You can write visualizers for public (obvious!) or internal or private types. The trick for non public types is to use the Assembly Qualified Name of the type you want to visualize. For instance, BizTalk 2006’s MessageContext property is actually an internal type (see purple type name below):
[assembly:
DebuggerVisualizer(typeof(<type of visualizer> ), typeof(<type of visualizer source>), TargetTypeName = “Microsoft.BizTalk.Message.Interop.MessageContext_ManagedViewOfNative, Microsoft.BizTalk.Pipeline, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”, Description = “<description>”)]
- Your visualizer code runs non JIT’ed. So make sure you do not perform too much work or it will be slow. If you do too much, the expression evaluator will time out and interrupt your visualizer with an “Expression Evaluation timed out exception”.
- Use DataGrid instead of DataGridView. I know I used a DataGridView in my visualizer, but the DataGrid is faster, especially when running non JIT’ed.
To illustrate these points, I wrote a BizTalk 2006 MessageContext debugger visualiser. You can download the complete solution BTSVisualizers.zip below. It works with Visual Studio 2005 and BizTalk 2006 only.
Load the visualizer solution in Visual Studio and build the release comfiguration.To install the MessageContext visualizer, shut down all instances of Visual Studio and copy BTSVisualizers.dll to %VS8ROOT%\Common7\Packages\Debugger\Visualizers. (If you installed Visual Studio at the default location, that would be C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\Visualizers) That’s it!
The next time you debug a pipeline (by attaching to BTSNTSVC.exe), you can hover the mouse on the “Context” variable of the message and see all entries in the message context:
Unfortunately, this visualizer will not display anything useful unless you are debugging a BizTalk artifact by attaching to BTSNTSVC.exe. This is because most debugging tools (like pipeline.exe) do not populate the message context.
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
I recently got this email from a WSS Adapter user
… I saw your 4 last web casts, it helped me a lot to get a good idea about thee WSS adapter.I have a question, Can you help me please and tell me how to add a row into SharePoint list and add an attachment to it? Where can I get more help about WSS adapter other then interrupt you? …
Unfortunately, the support for lists is not that rich in this release of the adapter. You can send messages to lists (create list row) but you cannot receive messages from lists or add attachments to a list item.
It’s very easy to add a row to a SharePoint list using the WSS adapter. The problem is that the adapter does not support adding an attachment to the row that was inserted.
In order to add a row to a list, you just have to send a message to that list the same way you would send the message to a document library. For instance, you can send a message to the Shared Documents document library or you can send a message to the Lists/Tasks list. All lists URLs begin with Lists/ so make sure you use the correct URL for the list. When sending a message to a list, the message will not be saved in the list (as it is saved in the document library) but the property promotion still happens. This means that you can use the Column 01 … Column 16, Column 01 Value … Column 16 Value send port properties in order to extract the values from the XML message and save them in the List columns. You can also hard code the SharePoint column values instead of taking them from the message. The Filename field is not used when sending messages to list, instead you will have to update the Title column.
See topic, ‘Supported Windows SharePoint Services Column Types ‘ in the BizTalk 2006 documentation (beta available for download here http://blogs.msdn.com/luke/archive/2006/02/03/524534.aspx ) for info on how to update particular SharePoint column types. You can also take a look at ‘Walkthrough: Module 3 – Accessing SharePoint Properties from an Orchestration ‘. Unfortunately that’s a little bit of an overkill because you need to do tutorial 1 and 2 before you can do 3, and also the main goal of the tutorial is to show how to use dynamic send ports. Sending a message to a list is a very small part of that tutorial and it’s done using a dynamic send port instead of the easier way which is using a physical send port.
In order to add an attachment to the list item you just created, you will have to write a .Net Component that invokes the Windows SharePoint Services web services and call that component from a BizTalk orchestration. Most likely you will have to use the http://localhost/_vti_bin/Listswsdl.aspx web service. You can take a look at this http://blogs.msdn.com/ahamza/archive/2006/03/15/WssAdapterBrowseUI.aspx project (source code is included) to see how I have used the WSS web services. That projects uses the Lists web service so you can probably even reuse some of the code.
More information on WSS adapter is available in the BizTalk 2006 documentation (pointer listed above), just search for SharePoint. You can also ask me questions anytime or just forward your questions to BizTalk discussion aliases ( http://blogs.msdn.com/kevin_lam/archive/2005/07/11/437590.aspx ).
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
Visual Studio 2005 added support for Debugger Visualizers. With debugger visualizers, developers can define what information (and in what form) is shown in the debugger for a specific type. There are many visualizers for various .NET types floating around. Here is a small list of the most popular ones: ASP.NET Cache, Regular Expression, XmlDocument (and other Xml related types), a powerful looking DataSet visualizer and there is even a WindowsIdentity visualizer.
I am not going to explain in details how to write your own visualizer. You can find step by step instructions on MSDN. Most existing debugger visualizers I mentionned in the previous paragraph also have home pages where you will find details on how to write your own or even source code.
I’d like to share some tricks you might find useful when writing your own visualizers:
- You can write visualizers for public (obvious!) or internal or private types. The trick for non public types is to use the Assembly Qualified Name of the type you want to visualize. For instance, BizTalk 2006’s MessageContext property is actually an internal type (see purple type name below):
[assembly:
DebuggerVisualizer(typeof(<type of visualizer> ), typeof(<type of visualizer source>), TargetTypeName = “Microsoft.BizTalk.Message.Interop.MessageContext_ManagedViewOfNative, Microsoft.BizTalk.Pipeline, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35”, Description = “<description>”)]
- Your visualizer code runs non JIT’ed. So make sure you do not perform too much work or it will be slow. If you do too much, the expression evaluator will time out and interrupt your visualizer with an “Expression Evaluation timed out exception”.
- Use DataGrid instead of DataGridView. I know I used a DataGridView in my visualizer, but the DataGrid is faster, especially when running non JIT’ed.
To illustrate these points, I wrote a BizTalk 2006 MessageContext debugger visualiser. You can download the complete solution BTSVisualizers.zip below. It works with Visual Studio 2005 and BizTalk 2006 only.
Load the visualizer solution in Visual Studio and build the release comfiguration.To install the MessageContext visualizer, shut down all instances of Visual Studio and copy BTSVisualizers.dll to %VS8ROOT%\Common7\Packages\Debugger\Visualizers. (If you installed Visual Studio at the default location, that would be C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\Visualizers) That’s it!
The next time you debug a pipeline (by attaching to BTSNTSVC.exe), you can hover the mouse on the “Context” variable of the message and see all entries in the message context:
Unfortunately, this visualizer will not display anything useful unless you are debugging a BizTalk artifact by attaching to BTSNTSVC.exe. This is because most debugging tools (like pipeline.exe) do not populate the message context.
by community-syndication | Mar 20, 2006 | BizTalk Community Blogs via Syndication
After you have upgraded from BizTalk 2004 to BizTalk 2006, you will be unable to read the old events generated prior to upgrade in the event viewer. In order to view those events, please follow the instructions below
- Copy the btsmsg.dll file from the BizTalk 2004 installation CD (For english, you can find it in <CD>\Msi\Program Files\1033).
- Copy this dll to the BizTalk Install Folder and rename it to BTSMsg_2004.dll
- Register this dll using regsvr32 and now, the Voyager event entries are available for viewing.
Note: This file will not be removed when the BizTalk 2006 is uninstalled. Please use /u option in regsvr32.exe to unregister the dll and then remove it from the install location.
by community-syndication | Mar 19, 2006 | BizTalk Community Blogs via Syndication
‘Thank you’ to all who attended last Thursday’s Twin Cities BizTalk User Group. You can get the ‘Orchestration Concepts: Message Construction, Direct Binding and Configuration’ presentation here. For those that were not at the presentation, note that the ‘Configuration’ section of this presentation focused on Orchestration Engine configuration and not configuration of applications running in BizTalk.
I packaged each demo’s source code into its own .zip file so they could be used as samples. ‘Readme’ notes on how to setup the samples, ‘reproduce’ the demos and what to look at to get the most out of the samples can be found later in this post.
Here are links to the samples:
- Calling Pipeline from Orchestration
- Orchestration Engine Configuration
- Partner (Port) Direct Binding (this sample uses the Inverse Partner Direct Binding pattern)
- (Update) Partner (Port) Direct Binding for BizTalk 2004
- Self-Correlated Direct Binding (this sample also used Message Box Direct Binding)
- (Update) Self-Correlated Direct Binding for BTS 2004
Note that the source code and readme.txt files can be used only with BizTalk 2006 (Beta 2) although only the ‘Calling Pipeline from Orchestration’ functionality will not work in BizTalk 2004 as the functionality does not exist in that release. If you are interested in 2004 samples request them through this blog.
If you would like more information on Direct Binding I suggest examining Charles Young’s Direct Binding article which you can fine here. There is also information on Direct Binding in Matt Milner’s ‘BizTalk Server 2004: A Messaging Engine Overview’ article.
—
Sample’s ‘ReadMe’ Notes
Call Pipeline from Orchestration:
- This sample shows how to call a send pipeline from an orchestration that aggregates two document messages into an envelope message.
- Review the CallPipeline.odx orchestration. This orchestration:
- Aggregates to instances based on MyItem.xsd into and instance of MyEnvelope.xsd using a custom Send Pipeline.
- Note the use of the Microsoft.XLANGs.Pipeline.SendPipelineInputMessages class to collect the item messages.
- Note the use of the Microsoft.XLANGs.Pipeline.XLANGPipelineManager class to call the custom pipeline.
- Create a Receive Port and Receive Location using the File Adapter and bind that port to the CallPipeline.odx’s logical Receive Port (the .zip file contains an ‘In’ directory that could be used for this.)
- Create a Send Port using the File Adapter and bind that port to the CallPipeline.odx’s logical Send Port (the .zip file contains an ‘Out’ directory that could be used for this.)
- Deploy the sample.
- Start the orchestration and receive location and send port.
- Copy and paste the ‘First MyItem.xml’ document into the Receive Location’s directory.
- Examine the output in the Send Port’s output directory to see that it contains two MyItem.xsd instances (although they are identical) within the MyEnvelope.xsd instance.
Orchestration Engine Configuration:
- This sample shows how to configure the orchestration engine to turn schema validation on, how to use AppDomain assignment and how to retrieve a value from BTSNTSvc.exe.config. T
