Here’s a handy little defrag utility.
This is a compelling article on why the operation property of an orchestration port should be uniquely named.
I was experiencing an unreported error when I was trying to dynamically call a BizTalk 2006 rules policy in C# code. The policy ran and gave me no exception information and was annoying me to no end!
It turns out the issue had to do with facts and namespaces. I didn’t discover this, however, until I learned from the link above how to put a debug trace into the policy so it would tell me what was going on.
Here’s a snippet:
TypedXmlDocument typedResult = new TypedXmlDocument(“ValidationResult”, validationResult);
TypedXmlDocument typedTransaction = new TypedXmlDocument(“Transaction”, transaction);
System.Collections.ArrayList FactList = new System.Collections.ArrayList();
DebugTrackingInterceptor debug = new DebugTrackingInterceptor(@”D:\trace.txt”);
Policy rulePolicy = new Policy(“ValidateTransaction”);
The last piece of the puzzle for me in working with generic messages to do away with a TON of duplication is to dynamically call a rules policy to validate outbound EDI messages.
This is some sample code I found on the blog mentioned above:
sCon = “Initial Catalog=Northwind;Data Source=(local);Integrated Security=SSPI;”;
con = new System.Data.SqlClient.SqlConnection(sCon);
dcNorthwind = new Microsoft.RuleEngine.DataConnection(“Northwind”, “ShipperCountry”, con);
xmlDocument = msgShippingRequest;
typedXmlDocument = new Microsoft.RuleEngine.TypedXmlDocument(“RoleLinkSample.ShippingRequest”,xmlDocument);
policy = new Microsoft.RuleEngine.Policy(“ShippingPolicy”);
msgOutgoingShippingRequest = typedXmlDocument.Document;
typedXmlDocument = null;
dcNorthwind = null;
This sample is based on Biztalk 2004, but should not differ in this instance for Biztalk 2006.
This is how we call maps dynamically in Biztalk 2006.
tMapType = System.Type.GetType(“DynamicMaps.Map_A, DynamicMaps, Version=22.214.171.124, Culture=neutral, PublicKeyToken=faed587cb93de4ea”);
transform (Out_Xml) = tMapType(In_Xml);
This is VERY cool…
I had two choices: created fifty separate orchestrations to handle all of the types and scenarios I needed to cover, or find a way to correlate untyped (XmlDocument) messages. I searched for the latter and found this article.
public IBaseMessage Execute(IPipelineContext pc, IBaseMessage inmsg)
string trackCode = Convert.ToString(System.Guid.NewGuid());
inmsg.Context.Promote(“TrackingID”, “http://Microsoft.Demo.Customer.CustomerPropertySchema”, trackCode);
I watched this demo and it is really impressive how quicky analysis cubes can be created and consumed in SQL Server 2005. I haven’t had the opportunity to use analysis services with SQL Server 2000, so I can’t appreciate how much easier it is in 2005. However, the benefits of cubed data become apparent pretty quickly while watching this short demo.
This article on SQL Server Query performance tuning appears to be very useful. Something to have in the toolbox.
This link is to a stored proc that will create Insert scripts for all of the data in a sql server table. A useful little bugger…
Yippie friggin doo da! I found this xsl script that strips namespaces and prefixes out of an xml document. This is going to be very useful in some Biztalk 2004 transformations that I doing.
This is what I ended up with:
<?xml version=”1.0″ encoding=”UTF-8″ ?>
<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform”>
<!– remove element prefix (if any) –>
<!– process attributes –>
<!– remove attribute prefix (if any) –>
<xsl:value-of select=”.” />