List of all the available Biztalk 2004 webcasts available at the following link

http://www.netologi.se/default.aspx?Contents=BizTalk_WebCasts

Labels: BIZTALK

Advanced basics. This faq covers some of the Advanced basic questions, which arise on most of the developers head during the initial stages. It's really good

http://www.netologi.se/default.aspx?Contents=BizTalkFAQ&Row=14#14

Labels: BIZTALK

I'm not going to explain how to call rules (Policy) from an Orchestration. If you want more information visit

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdk/htm/ebiz_prog_rules_ffhc.asp

It took me 3 hours to figure out how to get the parameter list inside the "Call Rules" shapes "Configure Policy" dialogue box with in the Orchestration.

Keep this points in mind:
When you create a Vocubularty Definition for XML element or attribute, with "Add New Definition" wizard. After selecting the Schema file, you make sure the "Document Type" text box has same namespace thats present in the schema but without the "http://" string.

for example: if you targetnamespace in the Schema is "http://saravana.biztalk.learning.schemas.basicpo1/", then you need to set the "Document Type" value to "Saravana.Biztalk.Learning.Schemas.BasicPO1"

If you are not doing this step correctly, parameter list won't appear in the "Call Rules", "Configure Policy" dialogue box.

Labels: BIZTALK

We need to agree with Martin's point on deployment issues we face with Biztalk Server 2004.

Read this post by Martin regarding all the Biztalk Deployment problems.

We mainly use Scott Colestock's NAnt-scripts for deployments, since we quickly concluded that it is absolutely essential to have an install script to perform deploytime configuration. We think it is practically impossible to perform all required steps manually w/o mistakes. It would take a really long time, good nerves and a lot of heavy-duty mousework to deploy manually into the production environment!

Our customers often want BizTalk after having seen the BizTalk Mapper in action, and heard some other appealing integration arguments. They expect/hope their own competent development staff to instantly be productive with this great tool. When we talk them through the finer points of deployment, they get really disappointed that they might need help from external consultants just to handle deployment of some simple change to their BizTalk configuration.

Also they do not like the idea that to deploy the same simple change they might need to completely shut down everything currently running, remove everything, essentially reverting to a blank installation, and then reinstalling everything again. Of course there are ways to partition your solution so that say redeployment of order processing do not interfere with say ongoing customer registration, but that instead complicates the deployment scripts, if for example "OrderProcessingOrchestration" is dependant on the same send port "SendToERP" as is "CustomerRegistrationOrchestration".

Also, the customers are surprised that VS.NET "Deploy" command.
* Does not work remotely.
* Does not handle redeploy for solutions partitioned into separate assemblies like schema-assembly, orchestration-assembly and pipeline-assembly.
* Does not perform bindings.
* Does not help with adding binding information to new (currently undeployed) orchestrations with "specify later"-ports.

I recently did a hands-on ad-hoc demo (=no scripted deploy) including a flat file transform in a pipeline, an orchestration, and a map, all housed inside one single assembly) for a few (competent) developers from a large potential customer, and the number of manual configuration steps, biztalk explorer refreshes, and host instance restarts and deployment related problems I encountered and had to solve made them a bit put down with the entire BizTalk concept we offered. I tried to explain that we would normally setup a deployment script to avoid all this, but had to agree that deployment, even scripted, is much more complicated than most people initially think. They now seem more inclined to handle a lot of "simpler" integration scenarios outside of BizTalk just because it seems too complicated to do really simple things with it.

Below are some of the deployment related problems we face in an ongoing project.

In the production environment:

* How to handle updates to the production environment with messages constantly arriving at the receive locations
* Avoid receiving messages when receive ports are running but orchestrations are stopped/undeployed -> "could not find matching subscription"
* Never, ever, lose messages.
* Minimize downtime.
* A seemingly "simple" redeploy like a new element in a schema often needs to stop and undeploy everything because of interdependencies, assuming one orchestration assembly and one separate schema assembly upon with the orchestration assembly is dependant.
* What happens with currently running/suspended orchestration instances when stopping BizTalk and undeploying orchestrations? Seems they must all be terminated before allowing un/redeploy (unless doing "side-by-side").
* Sometimes it is possible to stop the receive ports, and wait until all running orchestrations have had time to finish, but this is of course impossible for real long-running orchestrations. Needs side-by-side versioning of orchestrations.
* Very delicate ordering requirements of undeploy and deployment of various artifacts.
* Different if side-by-side w/different version numbers, or update with same version.
* Stop relevant ports first
* Make sure no interesting orchestration instances are alive. Else wait!
* Redeploy
* Restart BizTalk to reload assemblies.
* Side-by-side even more complex, but required with long-running orchestrations!
* No samples or external tools (Scott Colestock's NAnt-deployment-scripts) seems to be built for:
* (re)deployment with side-by-side versioning
* correctly handle redeploy with messages constantly arriving at the receive locations
* probably because there are no generic solution, and even getting the specific solution for your specific BizTalk project right is hard.
* We have a few orchestrations that gets executed frequently and runs for a minute or so, so we need to stop the ports, and wait for those to end before redeploying. Unfortunately we have not had time to incorporate this behaviour in our deployment scripts, so we need to remember to do this manually.
* We have not had the time and energy to fully investigate the side-by-side scenario, and change our deployment procedure to that method. Needs a few custom tools and major modifications of the deployment scripts in order to work as well as our current scripts.

* At least with Scott Colestock's NAnt-scripts, redeploy does undeploy based on new bindings (which for example does not handle a rename of a port or orch)
* Need to store deployed config with new name after successful deploy, and undeploy using that.
(Avoid removing/uninstalling that file during installation of update components)
* Probably possible to extract current bindings with BTSDeploy Export, and undeploy using that.

* Deploy HAT Message Property Tracking settings and Orchestration/Pipeline Inbound/Outbound message bodies
* Message property tracking settings are reset on redeploy.
* Had to build custom tool to re-configure message property tracking after each redeploy, but before receiving any messages, since tracking is a requirement.
* However... orchestration and pipeline tracking settings are *not* reset on redeploy.

During development:
* Chicken-or-egg situation when adding new orchestrations with a scripted environment.
* Must have orch in binding file, but cannot export bindings before first deploy.
* Therefore one often has to do some hand-editing of the binding files.
* This has proved to be a major problem for our junior developers. Re-deploying with the NAnt-script works great when they only update the assemblies, but when they need to add or change the configuration of ports/orchs they sometimes get stuck in limbo getting things half deployed, half undeployed, not being able to get out of the mess by themselves. They cannot undeploy because "something" they cannot find among the myriad of existing ports is referencing a schema or pipeline they try to remove, and therefore they cannot deploy and are also unable to revert to an older version!

* Deploy on different machines with different configuration, for example a test server w/o MSMQ/T Adapter
* We have development machines we cannot install MSMQ/T on, because they need dynamic IP and MSMQ.
* Have to replace MSMQ/T with FILE adapter in binding files.
* This particular scenario simplified with the recent release of the MSMQ adapter.
* This is also made simpler by the latest release of Scott Colestock's NAnt-scripts, which we haven't had time to migrate to.

* No way to automatically increment btproj file version and assembly version (current version updaters assume attributes AssemblyInfo.cs file)
* Sometimes the MSI-setup seems to not replace existing DLLs when upgrading (not deploying to biztalk, but rather installing the necessary scripts and assemblies to do so) maybe because the version numbers of the DLLs have not changed, although this might be due to something else. (Not a BizTalk-specific problem in any case)

* No way to automatically increment installer version (and product/package code) - also not a BizTalk-specific problem, but stops us from making a fully automated build and deploy process, without buying or making custom tools.

/Martin
Software Engineer
Softronic Syd AB
www.softronic.se
Sweden

Labels: BIZTALK

Lets take a sample condition where you want to map an element from the source schema to target schema if there is a particular value in the element.

Let me make it clear. Let us take a source schema as shown below:

<ns0:PO xmlns:ns0='http://Saravana.Biztalk.Learning.Schemas.BasicPO1'>
<Order>
<OrderNumber>OrderNumb</OrderNumber>
<Status>OKs</Status>
</Order>
</ns0:PO>

if the incoming message has the value of the element "Status" = "OK" then we want the element "Status" to be present in the outgoing message, if the value is something else then we don't need this element in the outgoing message.

Have you ever encountered such a problem? Solution for this problem in 4 easy steps.

1. Create a new map and configure the source and target schema as shown in the below figure.

Drag a Logical Equal functoid and Advanced "Value Mapping" functionoid.

2. Set the Logical Equal functoid Input parameters as shown in below figure


3. Set the Value Mapping functoid Input parameters as shown in below figure


4. Configure and run the solution by creating a Receive port,Receive Location and Send port basic setup (As you guys know!!). and configuring the map in the receive port.

It's that simple.

Labels: BIZTALK

Have you ever wondered how to control the Orchestration Dehydration time?

modify your BTSNTSvc.exe.config file as explained in the following link. (Biztalk Documentation Rocks!)

Look at the sample at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdk/htm/ebiz_prog_orch_jzex.asp

Labels: BIZTALK

No stories associated with the situation! Straight to the point.

Maximum polling interval at which the messaging agent polls the message box is determined by these values in the adm_ServiceClass (Biztalk management database) table.

The values are in milliseconds, default value is 500 milliseconds.

Now, you know what to do? ;)

Labels: BIZTALK

Do you get panic attack by hearing this jargon words in Biztalk world?

No worries! They are quite simple.

They are just design patterns, the way you implement your business process.

1. Parallel Receive
Condition: you wait for all the messages to come into your business process before the processing starts. Example: If you need to process something after receiving quotation (message) from all your manufacturers.

Key steps in your orchestration
* Drop Parallel action with 2 or more Receive shapes in the beginning.

* Activate = True in all the receive shapes

* Initializing Correlation Sets = "somecorrelationset" in all the receive shapes. (You need to define a correlation set with an element unique across all the messages you receive).

2. Sequential Receive
Condition: Either you receive same type or different type of message one after the other; you need to wait until you receive some kind of control message to say "That's the end", or keep receiving “n" number of messages.

Key steps in your orchestration
* Set Activate = True in the first Receive Shape, Initializing Correlation Sets = “somecorrelationset” (You need to define a correlation set with an element unique across all the messages you receive).

* Set Activate = False in the following receive shapes, Following Correlation Sets = “somecorrelationset”, and

* Put a Loop across Receive shape. Terminate the loop based on your condition either after receiving “n” number of messages or after receiving the control message.

Labels: BIZTALK

DigitalDepositLtd\Saravana.Kumar

I'm Saravana (hard core Microsoft Guy!!). To keep it simple serious lover of .NET/Biztalk, worked with the products for a long time now. Lucky enough to get into some of the exiciting projects.

My project experience includes working with Microsoft, Accenture, BT Syntegra, MarchFirst, Unilog, Thales, Axa, Inchcape and few more

Some of my career highlights:
MCAD Charter Member ( One among the first 50 to clear in UK in 2002).
Written some articles for Wrox (now Apress) during the beginning days of .NET (alpha/beta). http://www.asptoday.com/Authors.aspx?ID=553

There are quite few great guys around in this area. Let me try to add something, I come across in day to day learning.

Labels: blagging