by community-syndication | Jun 1, 2005 | BizTalk Community Blogs via Syndication
I guess the BizTalk Server 2006 CTP (Community Technical Preview) version will be distributed to TechEd 2005 attendees. I used be involved in a customer program introducing BizTalk Server 2006 to real customers. When they faced the major features of BizTalk Server 2006, they surely seemed to be quite satisfied with the enhanced features of the management, BAM, FF wizard, and so on. I hope you could get same feelings with the CTP version sooner or later. And..you will surely need this installation guide of the CTP version after getting the real software.
by community-syndication | Jun 1, 2005 | BizTalk Community Blogs via Syndication
Abstract: You can create a BizTalk message from a custom .NET class, instead of using an Xsd schema. This practice has some pros and cons. Let’s see
Usually, the most common process is to start creating Xsd schemas, and use them in Orchestrations, to define BizTalk messages. But, why would you like to have BizTalk messages based on Xml? It seems obvious that all messages should be Xml based, but in fact, sometimes Xsd/Xml is not necessary and adds complexity.
When is Xsd/Xml needed?
Xml messages are very nice if you need Messaging. That is, interoperatibility, external communications, schema publication. But surprisingly, I find many situations where people are defining Xsd schemas for Xml messages where Xml is not needed at all. Well, Xml is still fashionable, so
If a message lives inside an orchestration (is being passed from within orchestrations), but it’s never going to be published externally, or is never going to be sent/received externally, there’s no advantage in using Xml. In fact, there’s no reason to use Xml.
Xsd hell: how do you create a message from the scratch?
It’s a well known issue that creating an empty instance of a message inside an orchestration is not easy. Having the xml string hardcoded is not very elegant. Pointing to a file is not very elegant at all. You would need the path harcoded. Well, you can put it in a .config file, but isn’t too complex to just create an empty message?
I’ve read some discussion about using Maps to create empty (or default valued) instances. Since I agree it’s a good idea, it’s still too complex to just create an instance of a message.
This message-from-the-scratch problem is inherent to the use of Xml, since a message is not instantiable.
Using a .NET class
You can use a .NET class, instead a Xsd schema. Define your orchestration message as a .NET type, using your class. Use references to XLANGs Base Types to promote your class properties to distinguised fields or properties.
Pros:
Instantiate it. Use constructors, destructors, static members for instance creation or whatever you want.
Use rich properties. Mark public properties as promoted or distinguished fields. Use get and set methods.
Reuse as objects in other projects.
Cons:
External publication and Interoperatibility. There is no Schema, so if you intend to publish it externally, what do you publish?
Dependency of XLANG assemblies, so limited reuse outside your BizTalk project.
Simple Sample:
Create a .NET class:
using System;
namespace STCEAI.Messages
{
[Serializable]
public class SimpleMessage
{
private string _id;
public SimpleMessage()
{
}
[Microsoft.XLANGs.BaseTypes.DistinguishedField]
public string Id
{
get{ return _id;}
set{ _id = value;}
}
public static SimpleMessage Create()
{
SimpleMessage msg = new SimpleMessage();
msg.Id = System.Guid.NewGuid().ToString();
return msg;
}
}
}
Note the property is marked as Distinguished Field in order to make it visible from within the orchestration. This attribute is in Microsoft.BizTalk.XLANGs.BaseTypes.dll. You can also mark it as a promoted property, assign a Namespace, and include all the Xml serialization attributes as needed.
Usage inside an orchestration, in a Message Assignment Shape :
SimpleMessage_msg = new STCEAI.Messages.SimpleMessage();
SimpleMessage_msg.Id = myId;
or better:
SimpleMessage_msg = new STCEAI.Messages.SimpleMessage.Create();
by community-syndication | May 30, 2005 | BizTalk Community Blogs via Syndication
I got got an email from Chirag in Nigeria with the following problem. He had a positional flat file which he needed to parse which looked like this (the ` marks the carrage return and like feed, EOF is the end of file marker remove these to test the file):
0120200300 01 THORNTON `
0120200400 01 OGIHARA `
0120200500 01 WILSON `
0080300101 JENNIFERMRS `
0080300201 BENJAMINMSTR EOF
There are two different schemas or ‘Sections’ of data here and they are identified by the first 3 digits at the start of each line 012 and 008. Cirag had written a parser in C# but he was concerned it was too slow and this was not the “BizTalk” way to do things.
1) Create a schema that looks like the one shown below:
2) Set the properties on the following nodes. The key properties which make this solution work are the Parser Optimisation, Lookahead Depth for performance the Lookahead Depth must be set to allow the parser to identify the first 3 characters of each record i.e. 012 or 008. This works in turn with the Tag Identifier property which matches different records with different areas in the schema i.e. the 012 records should be parsed into the K20 parent node area and the 008 into the K30 parent node area, this is quite a powerful piece of functionality. The most common use for the Tag Identifier property I have seen is with correctly parsing header and footer records into a schema.
Note you will need the BizTalk 2004 SP1 installed to set the Parser Optimisation, Lookahead Depth and Allow Early Termination properties in the schema properties dialog or you will need to open the schema and set these using notepad or some other editor.
Node Property Name Property Value
Schema Schema Editor Extension Flat File Extension
Parser Optimisation Speed
Lookahead Depth 3
Allow Early Termination No
AirlineMessage Structure Delimited
Child Delimiter Type Hexadecimal
Child Delimiter 0x0D 0x0A
Child Order Infix
K20 Structure Positional
Tag Identifier 012
Tag Offset 0
Max Occurs *
Min Occurs 0
PLen Positional Length 4
Key2 Positional Length 2
Key3 Positional Length 2
ChangedFlag Positional Length 1
PartyNo Positional Length 2
Remark Positional Length 32
SplName Positional Length 6
SurName Positional Length 67
K30 Structure Positional
Tag Identifier 008
Tag Offset 0
Max Occurs *
Min Occurs 0
PLen Positional Length 4
Key2 Positional Length 2
Key3 Positional Length 2
ChangedFlag Positional Length 1
Name Positional Length 67
3) Now you’ve got the schema lets test it there are two easy ways to test the schema either:
a) Right click the schema in the solution explorer choose properties set the entries in the dialog to the following
Now Right click the schema in the solution explorer again and select validate instance. If all goes ok the the output window should display something like the following:
Invoking component…
Validation generated XML output <file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\_SchemaData\TestElement_output.xml>.
Validate Instance succeeded for schema TestElement.xsd, file: <file:///C:\Project\Artifacts\Biztalk Projects\UnuniformPositionalFlatFile\Test.pos>.
Component invocation succeeded.
Double click on the Validation generated XML output link and the xml output result of the file will be displayed. Then click in the pane in which the XML is displayed hold down the Ctrl key and press K and D this will format the result xml correctly so you can view it.
b) Call the the Flat File Dissasembly utility FFDASM.exe. the easiest way to do this is to create a bat file with the contents like the following:
c:
cd C:\Program Files\Microsoft BizTalk Server 2004\SDK\Utilities\PipelineTools
ffdasm.exe “C:\path\inputFlatFileName.pos” -bs “C:\path\schemaName.xsd” -c -v
pause..
The output should look like:
<AirlineMessage xmlns=”http://UnuniformPositionalFlatFile.Test“>
<K20 PLen=”0120“ Key2=”20“ Key3=”02“ ChangedFlag=”0“ PartyNo=”0“ Remark=”01“ SplName=”” SurName=”THORNTON“ xmlns=”” />
<K20 PLen=”0120“ Key2=”20“ Key3=”04“ ChangedFlag=”0“ PartyNo=”0“ Remark=”01“ SplName=”” SurName=”OGIHARA“ xmlns=”” />
<K20 PLen=”0120“ Key2=”20“ Key3=”05“ ChangedFlag=”0“ PartyNo=”0“ Remark=”01“ SplName=”” SurName=”WILSON“ xmlns=”” />
<K30 PLen=”0080“ Key2=”30“ Key3=”01“ ChangedFlag=”0“ Name=”JENNIFERMRS“ xmlns=”” />
<K30 PLen=”0080“ Key2=”30“ Key3=”02“ ChangedFlag=”0“ Name=”BENJAMINMSTR“ xmlns=”” />
<AirlineMessage>
R. Addis
by stephen-w-thomas | May 25, 2005 | Stephen's BizTalk and Integration Blog
NAcks or Negative Acknowledgments are small SOAP messages that exist in BizTalk when a messaging error occurs. This happens when adapters fail, pipelines fail, messages do not match subscriptions, ect.
These messages can be subscribed to and a business process can be written to react to all of these messages or specific error codes.
This sample Orchestration shows how simple it is to catch these messages. To subscribe to a NAck, just create a subscription to: BTS.AckType = NACK. It’s that easy!
Download: NAck Catching Sample
Setup: Download and extract the solution. Create a receive port that causes a routing failure. Drop a message and watch for the output in the Out folder.
For a routing failure NAck, the following properties are available in the message context and could be accessed inside the Orchestration:
AckDescription
AckFailure Category
AckFailure Code
AckID
AckInboundTransportLocation
AckOwnerID
AckReceivePortID
AckReceivePortName
AckType
With this information, logic could be included inside the Orchestration to extract / reprocess a message or log the error to an additional notification facility (other then the event log since it would already be logged there).
by community-syndication | May 25, 2005 | BizTalk Community Blogs via Syndication
The more I work with the Rules API the more I’m convinced that the Vocabulary element was only created for the BRC. The most generous I can be is that someone came up with a good idea for the BRC and “retrofitted” it for the API. There are two reasons for this;
- The API is unsupported and undocumented.
- The BRL (Business Rules Language) can function happily without it – in fact a rule can reference directly the document element / .NET method etc.
If you take a look at the following two bites from the exported rule store, UI think you’ll see why I come to this conclusion;
The following is in effect a definition of a string literal in the export vocabulary
<vocabularydefinition id=”54e58c56-e279-4729-b0d4-2e7bfbef989e” name=”TransferControlAccount” description=””>
<literaldefinition type=”string”>
<string>222222</string>
</literaldefinition>
<formatstring language=”en-US” string=” Transfer Control Account” />
</vocabularydefinition>
The following is taken from an extract of an action. This interesting thing to note is that the literal value “222222” is also specified, along side the link to the vocab entry specifying it;
<function>
<vocabularylink uri=”2e2bb376-b4ac-4d42-9573-cdf42088f681″
element=”453cb556-e96e-4e10-b456-96bf6d1313c6″ />
<classmember classref=”Accounting” member=”AddAccountingEntries” sideeffects=”true”>
<argument>
<constant>
<vocabularylink uri=”2e2bb376-b4ac-4d42-9573-cdf42088f681″
element=”54e58c56-e279-4729-b0d4-2e7bfbef989e” />
<string>222222</string>
</constant>
</argument>
</classmember>
</function>
So why would this redundant data be here? Performance? I doubt it. The whole “immutability” of Rules and Vocabularies makes sense from a version management perspective until you actually start using them. Imagine the scenario; You have defined your Vocabulary before starting your rules (This is required because you can’t reference a Vocabulary from your rules until that Vocabulary has been published – this in itself is predicated on knowing all the terms up front – big assumption!). You define 25+ rules, using multiple references to your vocabulary. Fine. You now publish the rule policy. At this point the world is still in order – version 1.0 of both rules and vocabulary are in a lotus type harmony. But what happens when you want to extend or amend the vocabulary? You create a new version of the Vocabulary (cut & paste!),make your amendments and publish it. Of course NONE of your rules will reference this new vocabulary (1.1) as all links reference 1.0 of the vocabulary. The only way to reference the new vocabulary is to create a new version of your rules (cut & paste!), and edit EACH AND EVERY reference to the vocabulary to repoint to the new version.
This isn’t new of course, and tools do exist to deal with it.
The BRC has been criticised for this “cut & paste” mentality, but in fact some of the problem goes back to the design of the rules system itself.
by community-syndication | May 24, 2005 | BizTalk Community Blogs via Syndication
As has been noted before in the lore of BizTalk, it sure would be useful to use a
real debugger with orchestrations – at least occasionally.
There are times when an expression shape winds up getting a bit sticky (not that I
would know…) and a debugger would be just the ticket. Other times, the exception
you are getting from the orchestration engine isn’t at all clear.
Still other times, seeing the actual contents of messages or context as you step through
would be interesting.
Jon has posted
on debugging orchestrations (in IL) with an ILDASM/ILASM
loop, and had also discussed building your orchestration assemblies manually (using
xsharpp.exe). (He correctly noted these approaches wouldn’t generate anything
supportable, but they work for spelunking.)
I wanted to suggest something a bit different – I wanted to go back instead to the
venerable BTS File Dump utility that Charles
released in May of 2004 (before the GenerateCSFiles registry key was
discovered…) and propose a different technique for symbolic debugging.
First, install Charles’ BizTalk File Dump utility – you can download it from here.
Fire it up, and change the output path in the utility to something easy, like c:\temp\BTSFileDump.
Here is the Edit/Debug cycle…(Start by making sure the file dump utility is running,
and click the “Start dumping files” button.)
-
Build your orchestration project (or whole solution if need be.)
-
Do a Ctrl-Shift-F (Find in Files) in Visual Studio, and change the “Look in:”
folder to c:\temp\BTSFileDump
-
Search for something in one of your expression shapes, say, “MyClass.Execute”.
The correct generated file (that the file dump utility grabbed) will appear in your
Find Results – open it up, and set a breakpoint. (Not on the xml designer portion
– on the actual code!)
-
From the Debug menu, choose Processes and attach to BTSNTSvc.exe. (Have more
than one?) Choose CLR debugging only – not native. The symbols should
be loaded automatically – no need to copy PDBs to the GAC.
-
Trigger your orchestration however you normally would. Bask in a picture like
this: (Puts a Petzold-style WindowProc to shame…)
-
Use QuickWatch to examine message contents/context, if you like – you’ll be interested
in expansions like
this one (where sampleRequest is a message in the orchestration.)
-
Find your problem, Debug-Detach All, and fix the problem in the orchestration.
-
Click “Delete all files in output path” in the file dump utility (to avoid duplicates)
and rebuild. Repeat the process if you need to. (To save time, consider
an external tool that just re-GACs the orchestration assembly and resets the host
process. See here.)
Note that this technique will work in a production setting. You could copy the
PDBs and sources to the production server, and use DbgClr.exe (in the Framework
SDK) or cordbg.exe to attach to the appropriate
host process.
Happy debugging…
by community-syndication | May 24, 2005 | BizTalk Community Blogs via Syndication
As has been noted before in the lore of BizTalk, it sure would be useful to use a
real debugger with orchestrations – at least occasionally.
There are times when an expression shape winds up getting a bit sticky (not that I
would know…) and a debugger would be just the ticket. Other times, the exception
you are getting from the orchestration engine isn’t at all clear.
Still other times, seeing the actual contents of messages or context as you step through
would be interesting.
Jon has posted
on debugging orchestrations (in IL) with an ILDASM/ILASM
loop, and had also discussed building your orchestration assemblies manually (using
xsharpp.exe). (He correctly noted these approaches wouldn’t generate anything
supportable, but they work for spelunking.)
I wanted to suggest something a bit different – I wanted to go back instead to the
venerable BTS File Dump utility that Charles
released in May of 2004 (before the GenerateCSFiles registry key was
discovered…) and propose a different technique for symbolic debugging.
First, install Charles’ BizTalk File Dump utility – you can download it from here.
Fire it up, and change the output path in the utility to something easy, like c:\temp\BTSFileDump.
Here is the Edit/Debug cycle…(Start by making sure the file dump utility is running,
and click the “Start dumping files” button.)
-
Build your orchestration project (or whole solution if need be.)
-
Do a Ctrl-Shift-F (Find in Files) in Visual Studio, and change the “Look in:”
folder to c:\temp\BTSFileDump
-
Search for something in one of your expression shapes, say, “MyClass.Execute”.
The correct generated file (that the file dump utility grabbed) will appear in your
Find Results – open it up, and set a breakpoint. (Not on the xml designer portion
– on the actual code!)
-
From the Debug menu, choose Processes and attach to BTSNTSvc.exe. (Have more
than one?) Choose CLR debugging only – not native. The symbols should
be loaded automatically – no need to copy PDBs to the GAC.
-
Trigger your orchestration however you normally would. Bask in a picture like
this: (Puts a Petzold-style WindowProc to shame…)
-
Use QuickWatch to examine message contents/context, if you like – you’ll be interested
in expansions like
this one (where sampleRequest is a message in the orchestration.)
-
Find your problem, Debug-Detach All, and fix the problem in the orchestration.
-
Click “Delete all files in output path” in the file dump utility (to avoid duplicates)
and rebuild. Repeat the process if you need to. (To save time, consider
an external tool that just re-GACs the orchestration assembly and resets the host
process. See here.)
Note that this technique will work in a production setting. You could copy the
PDBs and sources to the production server, and use DbgClr.exe (in the Framework
SDK) or cordbg.exe to attach to the appropriate
host process.
Happy debugging…
by community-syndication | May 23, 2005 | BizTalk Community Blogs via Syndication
Brennan and I are still planning to present on patterns at tech-ed, titled: %u00e2%u0080%u009cImplementing Real World Patterns with BizTalk 2004.%u00e2%u0080%u009d Stay tuned, as we will post a general overview of what we will be discussing, as well as links that will be relevant to our discussion. Once Tech-Ed is complete, we will be posting the full code and PowerPoint presentation(s). We are looking forward to seeing you there….
by community-syndication | May 19, 2005 | BizTalk Community Blogs via Syndication
I am so glad to see the updates to the native adapters in BizTalk 2006. Scott Woodgate posted a document on the changes here. (you might need to join the BizTalkServerStuff group if this link doesn’t work) I was lucky enough to spend some time with the adapter framework over the past few months, and the behavior of the native ones with 2004 left me scratching my head a few times. Anyhow, I really like the Adapter Framework despite not liking the examples built on it that are included with BizTalk. I’ve also been surprised that the community hasn’t strucken out and developed a bit more. There’s the potential for great extensibility, and it’s not too complicated once one takes a couple weeks to get oriented. The SDK sample adapter with 2004 is way overbuilt in my opinion. Plus it uses the SystemMessageContext class which is on the list of unsupported classes. I honestly had enough with the SDK samples once I found that guy being used, so I don’t know if there are any more or not. Anyhow, kudos to the BTS team for spending some time on these! I think they’ll make a bigger splash than most people anticipate….
by community-syndication | May 19, 2005 | BizTalk Community Blogs via Syndication
Once you’ve got your SOA all sorted – IIS can run out of available connections pretty quick due to things like Web Services calling other WebServices on the same box using up valuable connections.
Here’s a great MSDN Article that gives you the tech. details so your WebServices will hum.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetchapt10.asp
