by stephen-w-thomas | Oct 5, 2004 | Downloads
This is another Sequential Convoy Message processing sample using an Orchestration. This sample uses the Parallel Action Shape to process multiple records at the same time. This could be used to slow down message processing inside Biztalk and process messages in a controlled manner.
This sample should work for BizTalk 2004 and BizTalk 2006.
Get more information from the original blog post on this topic: http://www.biztalkgurus.com/biztalk_server/biztalk_blogs/b/biztalk/archive/2004/10/05/parallel-sequential-convoy-in-biztalk-server-2004.aspx
by community-syndication | Oct 4, 2004 | BizTalk Community Blogs via Syndication
This simulates an orchestration callrules action from code:
MyArrayList = new System.Collections.ArrayList();
MyPolicy = new Microsoft.RuleEngine.Policy(YourPolicyName);
MyTracer = new Microsoft.RuleEngine.DebugTrackingInterceptor();
You will have to create your facts in here. Use TypedXmlDocuments or custom objects (see the BizTalk help for samples)
MyArrayList.Add(MyFact1);
MyArrayList.Add(MyFact2);
MyPolicy.Execute(MyArrayList.ToArray(),MyTracer);
MyPolicy.Dispose();
System.Diagnostics.Trace.WriteLine(MyTracer.GetTraceOutput());
The aboveline will redirect the traces to the windows event trace.
Use the excellent debugview utility from sysinternals to view the traces.
by community-syndication | Oct 4, 2004 | BizTalk Community Blogs via Syndication
I applogize for being anything but prompt on this.
The zip file can be found here.
Steps for setting up Role Link Sample –
1. Create a receive port in BTS Explorer
2. Create 2 send ports – RoleLinkTest_Approver1 and RoleLinkTest_Approver2
3. Set your transports, send or receive locations, etc for your ports
4. Create a party called Approver1. Choose RoleLinkTest_Approver1 as their send port.
5. Create a party called Approver2. Choose RoleLinkTest_Approver2 as their send port.
At this point you should be able to deploy the project. Once the project has been successfully
deployed, you should now have a new Role listed in BTS Explorer called
RoleLinkSample.RoleLinkTestOrchestration.Purchasing.Approver. This is from the role link type we
created earlier.
6. Right click on the new Role and select “Enlist Party”. Choose are 2 parties. From this point
forward, if you wanted to add new parties (for new trading partners perhaps), you would just repeat
steps 4,5 and 6…it’s that easy!!!
Now you can run the test files through. Read back through the previous post on role links, and
follow along this example (pay attention to the expression shape that initializes the ports).
Hopefully it will make a little more sense.
Please let me know if you have any questions, or if the setup instructions are lacking.
ooops, almost forgot..take a look at the 2 files you’ll be submitting, and don’t forget to point the project to a keyfile.
Todd
by community-syndication | Oct 3, 2004 | BizTalk Community Blogs via Syndication
Here’s a presentation containing an overview of the flat file parser annotations that can be manually inserted into the BizTalk message schema. This is part of a presentation I gave at the Belgian BTS user group meeting a couple of weeks ago.There is also a sample project containing different schemas per annotation showing each annotation’s purpose. My main source of information was the BizTalk newsgroups where David Downing makes the beautiful weather for this topic. Just for the record: as usualeverything is ‘AS IS’, so there’s no warranty at all…
BTW this is my first post using the Simple Blog EditorInfoPath form that I found thanks to Capo
by community-syndication | Oct 2, 2004 | BizTalk Community Blogs via Syndication
Before I begin, I promise I am working on getting my role link example up here. There was some confusion with server space to upload the example to.
Ok….I know when I first started with BTS’04, it was slightly confusing to me what the whole host/host instance thing was. A fairly new concept from the previous versions. But, once the concept sinks in (things take longer for me 😉 ), it’s actually extremely useful.
So, we know that the Host is a “logical container”, and the Instance is the “physical container” for all your adapters, orchestrations, etc. What can we do armed with this knowledge? When we’re developing, everything runs under the default BizTalkServerApplication, and life is good. But, we need to start thinking about production, and how this solution is going to run efficiently, be highly available, and be easily scalable. This is were hosts and host instances come in.
It is best to decide on your hosts in the very beginning when planning your production environment. Take a look at the design of your solution, look at the expected message volume, the different methods of receiving and sending messages, service level agreements, and hopefully by now you will have tested some of your design to get an idea of performance. I find it is much better to create hosts down to the granular level. By this I mean if you are receiving messages real-time, some as batch, some as file transports, some as HTTP, break your hosts down accordingly. If you have some orchestrations that perform worse than others (a convoy perhaps), take that into account. It doesn’t necessarily mean you have to create a host for each one, but lets say you your batch messages take a lot of processing power…put those in their own host so you can isolate them and not affect your realtime messages. Breaking your hosts down at a granular level will make it much easier to reconfigure your system once you are stress testing and you find you need to re-shuffle your configuration to increase performance. This is because once you have your hosts created, and you have configured your adapters, orchestrations, etc to run in those hosts, all you need to do is create a new instance through BizTalk Admin console on whatever server you want it to run on. Let’s say that you have one instance of your host for batch files on a server (which you wouldn’t do because you want to account for failover also….), and that server is heavily taxed, slowing throughput of all your batch files. It is very easy to put another server out there, and simply configure a new host instance on it. If we had not separated our hosts initially, it would be much more difficult to now split out that functionality.
Another good reason to create different hosts is for security reason. I won’t go into detail here, but remember that hosts can be associated with different windows groups, and host instances can be configured to run as specific accounts.
As you can see, hosts and host instances provide us with load balancing. BizTalk internally handles load balancing through instances of the host. If you have instances of a host running on 3 separate servers, then BTS will handle dividing the load amongst the 3 boxes. If one box were to fail, then the 2 remaining boxes would pick up the slack. Similarly, if you need to add another box to decrease the load on the current 3, you can just configure a new instance of the host on a server, and BTS will now balance the load between the 4 boxes.
So, remember to seriously think about your hosts early on. Think in terms of performance, functionality and scalability. Read the paper on High Availability for BizTalk ’04.
by community-syndication | Oct 1, 2004 | BizTalk Community Blogs via Syndication
As appearantly everyone is eagerly looking for a gmail account, I will give away a few more. (At least, my previous blog makes me think that :-))
I’ll invite to gmail, the first 5 people who can tell me why I implemented my streaming pipeline component using multiple threads instead of just one :-p.
[Yes, that’s right 🙂 You’ll have to read the article on custom pipeline processing for this one :-))))))))))) ]
P.S. Make sure you include your name and current emailaddress in your comment as I need these to invite you.
[Update: I’ve invited the people who responded. If you don’t receive your invitiation, please let me know.]
by community-syndication | Sep 28, 2004 | BizTalk Community Blogs via Syndication
Since Virtual Server has been released, I got asked the question several times so I figured I’d put the answer here where everybody can find it. Knowledge Base Article 842301 says something like:
Current released versions of BizTalk (2000, 2002 ,2004) in any flavor (Enterprise, Developer …) are “best effort support” on virtual machines (Virtual PC and Virtual Server). Any case opened with Microsoft Support will be supported on a best effort basis and you may be asked to reproduce the problem on physical hardware during the course of troubleshooting the issue.
Not supported does not mean that it will not run: it may very well run fine or you may run into subtle issues. Not long ago a Microsoft Technology Specialist attempted to run BizTalk on a three weeks development project. According to him, this is not worth wasting the effort again. They ran into issues and none of them reproduced on real hardware. I am sure we can find individuals who have been running BizTalk on Virtual PC / Virtual Server without any problem so far. It probably depends on what you are doing.
If you feel lucky and want to try it out by yourself, this thread (chosen among many others) discusses some tips that might help you. While running a BizTalk server on a virtual machine for development purposes might be fine, I would definitely advise against running a production server under a virtual machine.
by community-syndication | Sep 28, 2004 | BizTalk Community Blogs via Syndication
Knowledge Base Article 838454 describes the new Microsoft.BizTalk.MessageBoxOM.MessageArchive object that was added to Microsoft.BizTalk.MessageBoxOM.dll. Currently, the package is only available through Microsoft Support.
There are a few things that this KB Article does not describe: remember that the Microsoft.BizTalk.MessageBoxOM.dll file is in the GAC. Currently, Visual Studio.NET 2003 does not allow you to add references to components in the GAC. To get past this, you can choose one alternative between these two solutions:
1 – Extract the dll from the GAC to a place where you can add reference to it (perhaps C:\<yourprojectdirectory>)
In a DOS prompt, run the following command:
copy %systemroot%\assembly\GAC\Microsoft.BizTalk.MessageBoxOM\3.0.1.0__31bf3856ad364e35\Microsoft.BizTalk.MessageBoxOM.dll <destination_path>
Where <destination_path> has been replaced by the path to your BizTalk project’s directory (for instance C:\MyProject)
2 – Manually edit the Visual Studio Project file (.csproj, .btsproj, .etc)
To add a reference to this assembly you must edit the project file (.csproj, .btproj, .etc) in a text editor. The following code snippet shows the code that must be added to the reference element of the project file to reference the assembly:
<Reference
Name = “Microsoft.BizTalk.MessageBoxOM”
AssemblyName = “Microsoft.BizTalk.MessageBoxOM”
HintPath = “<SystemRoot>\assembly\GAC\Microsoft.BizTalk.MessageBoxOM\3.0.1.0__31bf3856ad364e35\Microsoft.BizTalk.MessageBoxOM.dll”
/>
by community-syndication | Sep 25, 2004 | BizTalk Community Blogs via Syndication
I’m over in Redmond currently for a couple of weeks working with the Biztalk Design Wins team doing some performance tuning on a solution for one of my customers, I’ve also been having a lot of fun catching up with my colleagues and friends from the product group, and hearing about some of the great work they are doing for future versions. During this work we have gotton some interesting data that I thought was worth sharing.
As you will have seen from one of my previous post’s, marking a port as Delivery Notification = Transmitted provides a great mechansm to allow an orchestrations to know whether a message was actually transmitted successfully as opposed to simply being successfully published to the message box. There is of course a performance cost for using delivery notifications this goes without saying. The reasons for the performance hit being two fold, firstly, the load on the engine and the message box will be increased since for every transmittion an ACK or NACK will be created, published and routed to the orchestration instance that transmitted the message. Secondly, the execution of the orchestation instance is serialized whilst the message is being transmited, of course, some of the cost of this serialized processing will be recovered by the additional concurrency from other orchestration instances running whilst a particular insance is dehydrated waiting for an ACK/NACK.
In general the cost of using delivery notifications is of course dependant on the design of the orchestrations and ports, but as a rought rule of thumb, the performance cost is around 50%, though for one scenario we did see that using delivery notification gave approaximately 30% the performance of the same solution not using them.
by community-syndication | Sep 25, 2004 | BizTalk Community Blogs via Syndication
Kevin Lam has recently started a blog, be sure to check it out, Kevin works in the Biztalk Design Wins team and I’m sure he’ll share some of the great experience he has gained designing and building enterprise solutions on Biztalk.
