by community-syndication | Jan 2, 2006 | BizTalk Community Blogs via Syndication
I’ve found a tool recently that will make blogging about BizTalk easier. It’s been around for a while but if you are like me and have never heard of it before, CopySourceAsHtml is very useful.
If you have been in the situation of wanting to post a code or XSLT snippet onto your blog and found yourself writing HTML to make it look like it does in Visual Studio (or resort to screen shots) then fret no more, CopySourceAsHtml will take anything that you can open in VS (source code related) and convert it to HTML for you.
The tool is written by Colin Coller and can be downloaded on the CopySourceAsHtml homepage. In addition, Colin has a blog which updates progress on the tool. I read that a VS 2005 version is soon to be ready.
A couple of tips when using it:
- After installing you should be able to open any C# source code page, highlight and right click a code snippet and see a new “Copy as HTML” item on the menu. But, if for example you want to copy XSLT, the item doesn’t show up. Use the edit menu instead.
- When you copy something as HTML, under general, uncheck the “Number lines from:” box unless you really want them and also check the “Embed styles” box since blog tools/some browsers wont recognize the style sheet that gets created. Embeding the style makes it a simpler operation.
by community-syndication | Jan 2, 2006 | BizTalk Community Blogs via Syndication
Recently we developed a time sensitive BizTalk application where a simple set of processing steps were invoked via a web service.
The external calling application (the application calling the BizTalk process) had just 5 seconds to complete its task. Since the BizTalk part was not very complex or resource intensive, we were achieving response times of 1 second, well within the 5 second margin.
During testing, though, we were getting intermittent timeouts because the BizTalk application was unloading itself from memory and causing the calling application to timeout. Basically it took more than 5 seconds for the unloaded BizTalk application to start itself up again and caused a failure.
BizTalk relies on a configuration file to store its application information. This config file contains settings for unloading an application from memory and is located at \Program Files\Microsoft BizTalk Server 2004\BTSNTSvc.exe.config. Full documentation can be found at Microsoft’s website but here is a working example you can download.
By default BizTalk has 2 shutdown settings which are:
SecondsIdleBeforeShutdown = 1800 (seconds, or 30 minutes)
SecondsEmptyBeforeShutdown = 1200 (seconds, 20 minutes)
The link below is a sample config file that never shuts down. We are isolating these “hot” processes on a separate server from the “cold” processes (processes that can safely unload). You can run hot and cold side by side as well but that requires more changes in the config file. If you set the SecondsIdleBeforeShutdown and SecondsEmptyBeforeShutdown to -1 they will always stay in memory.
Note that this is increasing the load on the server but for time sensitive situations this could save you a rash of intermittent errors in production. Note also that you shouldn’t do this unless you really need to, unloading saves resources and with most integration scenarios the few seconds it takes to start up are minor.
You can backup your current file, download this BTSNTSvc.exe.config zip file and extract it, then stop and start your BizTalk host to see it work.
by community-syndication | Jan 2, 2006 | BizTalk Community Blogs via Syndication
I’ve noticed that – despite a fair bit of discussion on the topic – many folks wind
up using atomic scopes simply to avoid serialization requirements for .Net types within
an orchestration. It isn’t surprising this is the past of least resistance –
after all, the relevant compiler error sort of suggests this as a fix:
error X2141: a non-serializable object type 'SomeAssembly.SomeComponent yourComponent'
can only be declared within an atomic scope or service
Recall that persistence will occur when messages are sent, when another orchestration
is started asynchronously (like via the Start Orchestration shape), when an orchestration
instance is suspended, when a host instance does a controlled shutdown, when a “wait”
state occurs (like a blocking receive or delay shape that makes the schedule a candidate
for dehydration), or when the orchestration completes.
It will also occur at the end of a transactional scope to assist with resuming in
an unambiguous state (and executing compensation logic.)
So…although the introduction of an atomic scope prevents serialization within the
scope, it introduces serialization at the end of the scope. This is
often a persistence point (read: database hit) you wouldn’t have had to live with
— if an atomic scope was introduced purely to get around the compiler error
above.
Now…sometimes the .Net component you are using indeed requires state – and you should
go ahead and implement a serialization strategy for that case. If the component
can be stateless, then you might consider making the methods you access “static”
to avoid the compiler-enforced requirement altogether.
There is a third case, however – where you know that serialization is not required
(given how your orchestration is structured) – but you don’t own the code for it,
either. For instance, you might want to use an XmlNode to hold the result of
a SelectSingleNode call on an XmlDocument. If your use of the XmlNode instance is
confined to a single expression shape…no state actually needs to be preserved.
So, in this case, consider wrapping the class as shown below. Here, we honor
the serialization requirement – but we don’t, in fact, do any serialization work.
Now, no atomic scope is needed (avoiding the associated performance hit). Use
this technique with care – the state management facilities in BizTalk are usually
a great asset.
/// <summary>
/// It can be helpful when dealing with xpath expressions within orchestrations to
/// make use of a System.Xml.XmlNode (or derivations) without having to deal
/// with the fact that XmlNode is not serializable. If usage is confined to a single
/// expression shape, we actually won't have any serialization requirements, and so they
/// have empty implementation here.
/// </summary>
[Serializable]
public class BizTalkXmlNode : ISerializable
{
private XmlNode _xmlNode;
public BizTalkXmlNode()
{
}
public XmlNode XmlNode
{
get{return _xmlNode;}
set{_xmlNode = value;}
}
public string InnerText
{
get{return _xmlNode.InnerText;}
set{_xmlNode.InnerText = value;}
}
// This is helpful to use as a static helper method because the xpath expression in
// biztalk returns a XmlNode - so direct comparisons to string literals won't work.
// (And the expression editor won't let you get the InnerText property...)
public static string GetInnerText(XmlNode node)
{
return node.InnerText;
}
private BizTalkXmlNode(SerializationInfo info, StreamingContext context)
{
// no state intended...
}
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
// no state intended...
}
}
by community-syndication | Jan 2, 2006 | BizTalk Community Blogs via Syndication
I’ve noticed that – despite a fair bit of discussion on the topic – many folks wind
up using atomic scopes simply to avoid serialization requirements for .Net types within
an orchestration. It isn’t surprising this is the past of least resistance –
after all, the relevant compiler error sort of suggests this as a fix:
error X2141: a non-serializable object type 'SomeAssembly.SomeComponent yourComponent'
can only be declared within an atomic scope or service
Recall that persistence will occur when messages are sent, when another orchestration
is started asynchronously (like via the Start Orchestration shape), when an orchestration
instance is suspended, when a host instance does a controlled shutdown, when a “wait”
state occurs (like a blocking receive or delay shape that makes the schedule a candidate
for dehydration), or when the orchestration completes.
It will also occur at the end of a transactional scope to assist with resuming in
an unambiguous state (and executing compensation logic.)
So…although the introduction of an atomic scope prevents serialization within the
scope, it introduces serialization at the end of the scope. This is
often a persistence point (read: database hit) you wouldn’t have had to live with
— if an atomic scope was introduced purely to get around the compiler error
above.
Now…sometimes the .Net component you are using indeed requires state – and you should
go ahead and implement a serialization strategy for that case. If the component
can be stateless, then you might consider making the methods you access “static”
to avoid the compiler-enforced requirement altogether.
There is a third case, however – where you know that serialization is not required
(given how your orchestration is structured) – but you don’t own the code for it,
either. For instance, you might want to use an XmlNode to hold the result of
a SelectSingleNode call on an XmlDocument. If your use of the XmlNode instance is
confined to a single expression shape…no state actually needs to be preserved.
So, in this case, consider wrapping the class as shown below. Here, we honor
the serialization requirement – but we don’t, in fact, do any serialization work.
Now, no atomic scope is needed (avoiding the associated performance hit). Use
this technique with care – the state management facilities in BizTalk are usually
a great asset.
/// <summary>
/// It can be helpful when dealing with xpath expressions within orchestrations to
/// make use of a System.Xml.XmlNode (or derivations) without having to deal
/// with the fact that XmlNode is not serializable. If usage is confined to a single
/// expression shape, we actually won't have any serialization requirements, and so they
/// have empty implementation here.
/// </summary>
[Serializable]
public class BizTalkXmlNode : ISerializable
{
private XmlNode _xmlNode;
public BizTalkXmlNode()
{
}
public XmlNode XmlNode
{
get{return _xmlNode;}
set{_xmlNode = value;}
}
public string InnerText
{
get{return _xmlNode.InnerText;}
set{_xmlNode.InnerText = value;}
}
// This is helpful to use as a static helper method because the xpath expression in
// biztalk returns a XmlNode - so direct comparisons to string literals won't work.
// (And the expression editor won't let you get the InnerText property...)
public static string GetInnerText(XmlNode node)
{
return node.InnerText;
}
private BizTalkXmlNode(SerializationInfo info, StreamingContext context)
{
// no state intended...
}
public void GetObjectData(SerializationInfo info, StreamingContext context)
{
// no state intended...
}
}
by community-syndication | Jan 2, 2006 | BizTalk Community Blogs via Syndication
Scott Woodgate has announced that he has taken a new role within Microsoft, leaving the Connected Systems Division and the BizTalk Server product team. Filling his role will be Mike Woods and Kriss Horrocks for BizTalk Server; Paul Andrew will continue to lead the Windows Workflow team. Scott’s new role will be on […]
