New BizTalk Adapters for WSE 3, SalesForce.com, and SQL Service Broker

by | Apr 27, 2006 | Stephen's BizTalk and Integration Blog

Wow, the guys at Two Connect have been very busy.  They have released three new adapters for BizTalk Server 2006. 



They are:



  • SalesForce.com (integrated with them in the past through .net as a BizTalk Adapter would be great)

  • Web Services Enhancements (WSE) 3.0

  • SQL Server Service


They have some upcoming web casts along with members of the Microsoft Product Teams to cover these exciting new adapters.



Make sure you check them out.  You can get more information on Jesus Rodriguez blog.

WSE 3, SalesForce.com, and SQL Service Broker BizTalk Adapters

by | Apr 27, 2006 | BizTalk Community Blogs via Syndication

Wow, the guys at Two Connect have been very busy.  They have released three new adapters for BizTalk Server 2006. 


 


They are:



  • SalesForce.com (integrated with them in the past through .net as a BizTalk Adapter would be great)

  • Web Services Enhancements (WSE) 3.0

  • SQL Server Service

 


They have some upcoming web casts along with members of the Microsoft Product Teams to cover these exciting new adapters.


 


Make sure you check them out.  You can get more information on Jesus Rodriguez blog.

Writing to Eventlog while working with maps using Eventlog Functoid in Biztalk Server 2004

by | Apr 26, 2006 | BizTalk Community Blogs via Syndication

While testing our maps at times when it fails we feel that what could have went wrong and we cant trace it because we don’t know what the output of the functiods are. Normally in a single map we use normally 50-60 functiods.Were do we start debugging our Map. It’s tough when we are under pressure to deliver it on time to debug a map. But it’s a part of our job to make sure that our map is stable. I thought of this functiod while working on a project where in I wanted to see the output of a specific Scripting functiod.


So I just planned to have one which will write to Eventlog any output of data type string. So now what we need to do is just use this functiod to insert into Eventlog.This functiod will return the string after writing it to Eventlog. So just at an overhead of 1 functiod we can test our map to perfection.Just build the solution and drop the EventlogFunctiod.dll in


C:\Program Files\Microsoft BizTalk Server 2004\Developer Tools\Mapper Extensions


And  also GAC it. Then add it in the toolbox and use it in your maps.


Hope it helps you in your project.


The code is given below


 


using System;
using Microsoft.BizTalk.BaseFunctoids;
using System.Reflection;
using System.Xml;
using System.Diagnostics;


//Summary
//This Class will write an entry in event log.
//It will take up 1 parameter as input and will output the same parameter after writing it to eventlog
namespace EventlogFunctiods
{
 public class EventlogFunctoid: BaseFunctoid
 {
  public EventlogFunctoid()
  {
   this.ID = 6464;   
   SetName(“EventLog”);
   SetTooltip(“Please pass only 1 parameter”);
   SetDescription(“This Functiod writes the specified parameter to Eventlog.It takes up only 1 paramter”);   
   this.SetMinParams(1);
   this.SetMaxParams(1);
   SetExternalFunctionName(GetType().Assembly.FullName,
    “EventlogFunctiods.EventlogFunctoid”, “EventlogFunc”);
   this.Category = FunctoidCategory.String;
   this.OutputConnectionType = ConnectionType.AllExceptRecord;
   AddInputConnectionType(ConnectionType.AllExceptRecord);   
  }
  public string EventlogFunc(string param1)
  {
   System.Diagnostics.EventLog.WriteEntry(“Eventlog-Functiod”,param1);
   return param1;   
  }
 }
}


If you find it tough to implement….just download the solution which is available at


http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=e986cc9e-bf71-4740-9dfc-1a2d166f8cad

Any queries or bugs would be appreciated because “To err is human”.

Pipeline Testing Library – Part 1

Pipeline Testing Library – Part 1

by | Apr 26, 2006 | BizTalk Community Blogs via Syndication

As I mentioned on a previous
post, I’ve been working on a helper library to test BizTalk Pipelines and Custom
Pipeline Components using NUnit or your unit testing framework of choice. I’ve uploaded
V1.0 of the library, which you can download from here.

The library is pretty straightforward to use, but I’m going to document its features
on this and following posts so that you can get started with it easily.

Preparing to use the library

First of all, you’ll need to build the library from the downloaded source code distribution,
using Visual Studio 2005. The distribution includes the unit tests for the library,
which you can run to verify it is working correctly, if you want.

To use the library once you’ve built it, you’ll want your projects to reference the
following three libraries:

  • Winterdom.BizTalk.PipelineTesting.dll

  • Microsoft.BizTalk.Pipeline.dll

  • Microsoft.BizTalk.Pipeline.Components.dll

    • >>

Creating Pipelines

To test a pipeline component, or a pipeline, the first thing you’ll need to do pretty
much is instantiate a pipeline. The library supports two different ways of doing this:
Create an empty pipeline and add the necessary components using code, or create an
instance of an existing BizTalk pipeline. Both of these operations are supported for
send and receive pipelines through the methods in the PipelineFactory class.

  • CreateEmptyReceivePipeline() and CreateEmptySendPipeline() create a new receive or
    send pipeline respectively, that has no components configured on any of its stages.
    You then are responsable for adding the necessary components to configure your pipeline
    as necessary; I’ll show later how this can be done.

    Here’s an example of how these methods can be called:

    SendPipelineWrapper sendPipeline =

       PipelineFactory.CreateEmptySendPipeline();

    ReceivePipelineWrapper receivePipeline =

       PipelineFactory.CreateReceivePipeline(typeof(XMLReceive));

  • CreateReceivePipeline() and CreateSendPipeline() create a new instance of an existing
    BizTalk pipeline. Each of these methods take a Type handle as an argument. When you
    compile a BizTalk project that contains a pipeline, said pipeline is generated as
    a new CLR type into your BizTalk assembly (with the same name as the .BTP file it
    is derived from).

    This is very convenient, as it allows you to just add a project or file reference
    to the BizTalk project where you designed the pipeline and use the type directly.
    In fact, built-in pipelines like the XMLTransmit or XMLReceive pipeline can be used
    just this way: simply reference the Microsoft.BizTalk.DefaultPipelines.dll assembly
    and write this:

    using Microsoft.BizTalk.DefaultPipelines;

    //
    …

    ReceivePipelineWrapper receivePipeline =

       PipelineFactory.CreateReceivePipeline(typeof(XMLReceive));


     

    • >

Configuring Components

If you’ve created an instance of an existing pipeline, you’ve probably set to
go and can skip this part (though you can still add new components to an existing
pipeline this way), if not, you’ll now want to add some components to each of the
stages you’re interested in to your pipeline.

To do this, you can use the AddComponent() method of each of the pipeline classes,
which take an object implementing IBaseComponent (a pipeline component) and an object
of type PipelineStage representing the stage you want to add that component to. The
PipelineStage class contains a set of static readonly objects you can use to refer
to the possible stages you can use, so you’ll never create an instance of this type
directly.

So, for example, if you want to add a new XML Disassembler component to the disassemble
stage of a receive pipeline, you can write this:

ReceivePipelineWrapper pipeline =

   PipelineFactory.CreateEmptyReceivePipeline();

IBaseComponent component = new XmlDasmComp();

pipeline.AddComponent(component, PipelineStage.Disassemble);


 

Here’s an example of adding an encoding component to a send pipeline:

>

SendPipelineWrapper pipeline =

   PipelineFactory.CreateEmptySendPipeline();

MIME_SMIME_Encoder encoder = new MIME_SMIME_Encoder();

encoder.AddSigningCertToMessage = true;

encoder.ContentTransferEncoding =

   MIME_SMIME_Encoder.MIMETransferEncodingType.Base64;

encoder.EnableEncryption = true;

pipeline.AddComponent(encoder, PipelineStage.Encode);


 

In a following post I’ll talk about configuring document specifications (schemas)
and executing the pipelines.

Document Explorer 2005 is installed from…?

by | Apr 26, 2006 | BizTalk Community Blogs via Syndication

Did I miss something or is the answer to this question harder to track down than it should be?


As documented in the ‘BizTalk Server 2006 Installation Guide – Multiserver.doc’, Document Explorer 2005 is a dependency for the BizTalk 2006 documentation.  So the operations team on my current engagement asks me where it comes from… and I respond that that is a good question and that I’ll have an answer for them in a couple of minutes. 


After a few tens of minutes I’ve inferred that it is part of the Visual Studio 2005 installation, based on this document: http://msdn.microsoft.com/vstudio/support/AdminReadme/default.aspx   ‘Help on Help’ leads me to believe that it could be (in the future?) installed from multiple products.

Demystifying Direct Bound Ports – Part 2

by | Apr 25, 2006 | BizTalk Community Blogs via Syndication

Message Box Direct Bound Ports


Message box direct bound ports, as its name implies, allows you to drop messages directly into the message box without an explicit recipient and it allows you to subscribe to messages, not from any particular sender, which meet certain criteria.  To configure a message box direct bound port set the ’Partner Orchestration Port’ property to ’Message Box’.


Sending a message on a message box direct bound port is equivalent to publishing the message to a message bus, in this case the message box.  For any published message there can be any number of subscribers for that message.  If there are no subscribers interested in the message at the time you publish it a persistence exception is thrown with an inner exception of subscription not found.


Sometimes when sending a message through a message box direct bound port you may have an implicit recipient in mind and will set properties to particular values that you know a subscriber(s) is looking for and is therefore used as a method for loose-coupling.


Recipients of the message can be any type of service that can subscribe to messages which include orchestrations and send ports.


Receiving a message through a message box direct bound port is equivalent to subscribing to a message bus with filter criteria.  For an activating receive shape the subscription will be the message type and the filter and for non-activating receive shapes the subscription will be the message type and the correlation set.


Every receive shape always includes the message type as part of its subscription. 


If you don’t add any filter criteria to the activating receive shape connected to a message box direct bound port then the subscription will be:


http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == MyMessageType


Which can be read as, “Give me every message whose message-type is MyMessageType”.  This is what differentiates a send port subscription from an orchestration subscription.  A send port subscription, if you don’t provide it with a filter, will only handle messages sent directly to it via a bound (specify-now or specify-later) logical orchestration port (i.e. the subscription for a send port includes its send port id as a clause OR’ed with it’s filter).  A message box direct bound receive port that does not have a filter explicitly added will receive every message that matches the message type that the port’s operation is configured for.  [Note: If the message-type is XmlDocument then this is a type-agnostic port.  Type-agnostic ports accept any message type.  To accomplish this the subscription won’t include a message-type, implying that it is not filtering based on message-type.  So if there is no filter on the port and the port is type-agnostic then the subscription will be empty and in this case will not match any incoming message as there are no predicates for the routing engine to match against.]


When using message box direct bound receive ports be careful to make the filter as specific as possible.  I typically caution developers to only use receive message box direct bound ports only when it is absolutely necessary or the benefits (e.g. loose-coupling) out-weigh the risks, as many developers make the mistake of not making their filter distinguishing enough.  The side effect of not having a distinguishing enough filter is that the orchestration can receive messages it didn’t intend to. 


An example of a mistake that is commonly made is the following; an activating receive shape with a filter using some custom property followed sometime later by a send shape sending the same message to a send port physically bound to an endpoint.  In this case the developer assumes that since the logical send port is bound to a physical send port then only that physical send port will get the message.  This is not the case.  What will happen is that after the first message is published to the message box an infinite number of orchestrations will be activated.  This will happen because the message being sent to the send port endpoint is published to the message box and, because every time a message is sent to the message box all subscriptions are checked for a match, the activation filter of the orchestration will match the message and a new orchestration instance will be started, then recurse to infinity.  If the orchestration is more complex and/or if the receive is using a correlation set as its subscription then the difficulty of trying to debug a similar scenario increases dramatically.


 



Figure 5 Orchestration that will consume its own messages


 


In this case the only way to not have the orchestration pick-up the same messages it is sending  (i.e. incorrectly activate a new instance of the same orchestration) is to either construct a new message and change MyProp property to some other value or send a message of a different message-type.

Cannot Link Field in BizTalk Server 2004 Mapper Tool

by | Apr 25, 2006 | BizTalk Community Blogs via Syndication

Has the BizTalk Server 2004 Mapper tool ever prevented you from linking a field in a map?  Have you ever spent two hours figuring out why?


Check to see if the field or record has a constant value.  If so, that is your problem.  The following is from the BizTalk Server 2004 documentation:


You cannot link to a Field or Record node in the destination schema that has a constant value associated with it. On the other hand, you can link to a required Field or Record node in the destination schema that has a default value associated with it. Note, however, that when you test the map, the default value will be used.


Have fun…


 

Demystifying Direct Bound Ports – Part 2

by | Apr 25, 2006 | BizTalk Community Blogs via Syndication

Message Box Direct Bound Ports


Message box direct bound ports, as its name implies, allows you to drop messages directly into the message box without an explicit recipient and it allows you to subscribe to messages, not from any particular sender, which meet certain criteria.  To configure a message box direct bound port set the ’Partner Orchestration Port’ property to ’Message Box’.


Sending a message on a message box direct bound port is equivalent to publishing the message to a message bus, in this case the message box.  For any published message there can be any number of subscribers for that message.  If there are no subscribers interested in the message at the time you publish it a persistence exception is thrown with an inner exception of subscription not found.


Sometimes when sending a message through a message box direct bound port you may have an implicit recipient in mind and will set properties to particular values that you know a subscriber(s) is looking for and is therefore used as a method for loose-coupling.


Recipients of the message can be any type of service that can subscribe to messages which include orchestrations and send ports.


Receiving a message through a message box direct bound port is equivalent to subscribing to a message bus with filter criteria.  For an activating receive shape the subscription will be the message type and the filter and for non-activating receive shapes the subscription will be the message type and the correlation set.


Every receive shape always includes the message type as part of its subscription. 


If you don’t add any filter criteria to the activating receive shape connected to a message box direct bound port then the subscription will be:


http://schemas.microsoft.com/BizTalk/2003/system-properties.MessageType == MyMessageType


Which can be read as, “Give me every message whose message-type is MyMessageType”.  This is what differentiates a send port subscription from an orchestration subscription.  A send port subscription, if you don’t provide it with a filter, will only handle messages sent directly to it via a bound (specify-now or specify-later) logical orchestration port (i.e. the subscription for a send port includes its send port id as a clause OR’ed with it’s filter).  A message box direct bound receive port that does not have a filter explicitly added will receive every message that matches the message type that the port’s operation is configured for.  [Note: If the message-type is XmlDocument then this is a type-agnostic port.  Type-agnostic ports accept any message type.  To accomplish this the subscription won’t include a message-type, implying that it is not filtering based on message-type.  So if there is no filter on the port and the port is type-agnostic then the subscription will be empty and in this case will not match any incoming message as there are no predicates for the routing engine to match against.]


When using message box direct bound receive ports be careful to make the filter as specific as possible.  I typically caution developers to only use receive message box direct bound ports only when it is absolutely necessary or the benefits (e.g. loose-coupling) out-weigh the risks, as many developers make the mistake of not making their filter distinguishing enough.  The side effect of not having a distinguishing enough filter is that the orchestration can receive messages it didn’t intend to. 


An example of a mistake that is commonly made is the following; an activating receive shape with a filter using some custom property followed sometime later by a send shape sending the same message to a send port physically bound to an endpoint.  In this case the developer assumes that since the logical send port is bound to a physical send port then only that physical send port will get the message.  This is not the case.  What will happen is that after the first message is published to the message box an infinite number of orchestrations will be activated.  This will happen because the message being sent to the send port endpoint is published to the message box and, because every time a message is sent to the message box all subscriptions are checked for a match, the activation filter of the orchestration will match the message and a new orchestration instance will be started, then recurse to infinity.  If the orchestration is more complex and/or if the receive is using a correlation set as its subscription then the difficulty of trying to debug a similar scenario increases dramatically.


 



Figure 5 Orchestration that will consume its own messages


 


In this case the only way to not have the orchestration pick-up the same messages it is sending  (i.e. incorrectly activate a new instance of the same orchestration) is to either construct a new message and change MyProp property to some other value or send a message of a different message-type.