Questions, comments, feedback, or problems with the tutorials for BizTalk Server 2006?? Step on over to Liza’s blog! Liza is a Technical Writer on the team and the author of the tutorials! She also just finished the documentation for the BizTalk Server Best Practices Analyzer!
URL: http://blogs.msdn.com/lizal/
Partner direct bound ports provide the capability of having inter-orchestration communication via ports.
To configure a partner direct bound port you must choose the orchestration and port for the ’Partner Orchestration Port’ property. When configuring the two partner ports you must have one side select the orchestration.port it will communicate with and the other side will select its own orchestration.port. This is a little non-intuitive but will be explained in the sections below. Also the port types for both ports must be the same, which implies that the message-types must also be the same. This is one of the places where the Type Modifier property on the port-type matters. To be able to direct bind to a partner port the port-type type modifier must either be internal for orchestrations within the same assembly or public to allow an orchestration from another assembly to bind to it. Finally, the polarities of the ports must be opposite. In other words, if one side is a send port then the other side must be a receive port.
There are two communication patterns that can be created; forward partner direct binding and inverse partner direct binding. These two patterns provide explicit inter-orchestration communication. By explicit I mean that there is an intended recipient orchestration (forward partner direct binding) or an intended sender (inverse partner direct binding). You can design implicit partner direct binding by having either the receiver be message box direct bound and create a filter that will accept messages from a particular sending orchestration or have the sender be message box direct bound and promote properties that will match a subscription on the receiving orchestration.
This is the typical communication pattern that is used for partner direct binding. Orchestration A has a partner direct bound send port that will send a message to Orchestration B on its partner direct bound receive port. To configure this forward partner direct binding you must have orchestrationA.sendPort1, which is of type portType1, select orchestrationB.receivePort1, which is also of type portType1, as its Partner Orchestration Port. orchestrationB.receivePort1 will select itself, orchestrationB.receivePort1, as its Partner Orchestration Port.
Figure 6 Forward Partner Direct Binding Configuration
On the sender’s side what this says is, “I will send messages to orchestrationB.receivePort1” and on the receiver’s side it says, “I will receive any messages sent directly to my receivePort1”.
Under the covers when messages are sent out of sendPort1 the orchestration engine will set the following properties:
BTS.Operation to the operation on the port being used.
BTS.PartnerPort to the name of the partner direct bound port configured in the Partner Orchestration Port property
BTS.PartnerService to the strong name of the orchestration referenced in the Partner Orchestration Port property
Note: the strong name of the partner service will usually look something like:
OrchNamespace.OrchTypeName, AssemblyName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fedcba9876543210
On the receive side the subscription will be (for brevity I will use the BTS namespace instead of http://schemas.microsoft.com/BizTalk/2003/system-properties as you would see in the actual subscription)
BTS.Operation == operation1 And
BTS.PartnerPort == receivePort1 And
BTS.PartnerService == MyTest.OrchestrationB, MyTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fedcba9876543210 And
BTS.MessageType == http://MyNamespace#MyRootNodeTypeName
Something to note here is that there is a strong binding from the sender orchestration to the receiver orchestration. By strong binding I mean that the sender orchestration is referencing the receiver’s strong name as its partner service. What this means is that if you want to change the receiver’s side or if you change the version of the receiver’s side you must update the design time configuration of the sender’s port. But the receiver has no explicit knowledge of the sender so the senders’ orchestrations can be updated without affecting the receiver.
This type of forward binding allows you to have multiple senders bound to the same recipient.
Figure 7 N:1 communication
Here orchestrationD would be doing some common asynchronous work needed by many different orchestrations.
This is not the typical communication pattern that is used for partner direct binding as the direction of binding is inverse of its direction of communication. Orchestration A has a partner direct bound send port will send a message to Orchestration B on its partner direct bound receive port. To configure this inverse partner direct binding you must have orchestrationB.receivePort1, which is of type portType1, select orchestrationA.sendPort1, which is also of type portType1, as its Partner Orchestration Port. orchestrationA.sendPort1 will select itself, orchestrationA.sendPort1, as its Partner Orchestration Port.
Figure 8 Inverse Direct Binding Configuration
On the sender’s side what this says is, “I will send a message to anyone who is listening for messages from my send port” and on the receiver’s side it says, “I will receive messages sent from orchestrationA.sendPort1”.
Under the covers when messages are sent out of sendPort1 the logic for setting properties is still the same as it was for the forward case. The orchestration engine will still set the following properties:
BTS.Operation to the operation on the port being used.
BTS.PartnerPort to the name of the partner direct bound port configured in the Partner Orchestration Port property
BTS.PartnerService to the strong name of the orchestration referenced in the Partner Orchestration Port property
On the receive side the subscription will
BTS.Operation == operation1 And
BTS.PartnerPort == sendPort1 And
BTS.PartnerService == MyTest.OrchestrationA, MyTest, Version=1.0.0.0, Culture=neutral, PublicKeyToken=fedcba9876543210 And
BTS.MessageType == http://MyNamespace#MyRootNodeTypeName
In this case the receiver is strongly bound to the sender implying that if you want to change the receiver’s orchestration or update the version then you must update the sender’s port configuration. The sender has no explicit knowledge of the receiver so the receivers’ orchestrations can be updated without affect the sender.
This type of inverse binding allows you to have a single sender communicate with multiple receivers.
Figure 9 1:N communication
Inverse direct bound ports allows for a recipient list pattern. The recipient list is determined by which receive ports are bound to a particular send port and is maintained as part of the orchestration design. Here either all of the recipient orchestrations can consume any message coming from the send port or they can each have a filter to determine which messages each of the recipients should consume from the sender.
One thing to be careful about is that if you are using a two-way port type with inverse partner direct binding then you must setup your filters to ensure that only one of the recipients will consume (i.e. subscription will match) the message. This is because a solicit-response port is expecting a single response and if multiple recipients get the message, then it will accept the first response and all subsequent responses would be suspended non-resumable. The engine won’t let that happen and it will instead throw an exception when you try to send the message indicating that there would be multiple recipients for a solicit-response request.
For beginners, who interested in learning BizTalk%u00ae Server 2006, the best place is Microsoft%u00ae BizTalk%u00ae Server 2006 for Developers
\n
\n
\n
\n
\n
\n
\n
\n
//–>
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n\n
“,0]
);
//–>
One of the more popular quirk in SharePoint 2003 (remember the YASQ’s?) was the alerting mechanism. The alerts in SharePoint 2003 are OK at first sight: you can create an alert for a complete list or document library, or just for one item. The problem is that you can only create an alert for yourself. This makes sense if you think of alerts as ’RSS-avant-la-lettre’. But lots of people would like to create alerts for other users as well. Unfortunately this was not available out-of-the-box, although you could customize SharePoint by installing various (free) web parts to overcome this issue.
Recently I discovered that this YASQ has become a YASR (Yet Another SharePoint Relief): in SharePoint 2007 you can create alerts for other users! Just navigate to a list or document library, and from the Actions menu choose the Alert Me item.
On the New Alert page you can specify the details about the alert: title, type and destination. The new (and exciting) thing is here that you can enter multiple user accounts to which the alert should be sent.
Further down on the page there are more innovations. In SharePoint 2007 you can create an alert which is based on a specific view which opens quite some interesting possibilities. Finally you can still choose the interval to sent the alert (immediate, daily and weekly). New here is when you select the daily or weekly summary that you can specify the exact time when the alert should be sent (e.g. a daily summary at 7.00 am in the morning).
So are alerts perfect in the release? I think there’s still some room for improvements: when you create an alert for multiple users actually multiple alerts are created. This is a disadvantage when you would like to delete or update the alert that you’ve created for multiple users at the same time (you can’t push forward those changes). And finally it’s not (yet?) possible to create an alert for all the content of a site. But don’t get me wrong, I still consider this as a major YASR!
The task: make a web user authenticated (either with him directly providing user ID or password or through domain, if he is already logged in) and run ASP.Net code under his/her ID.
Frankly, that’s very easy, but I noticed that sometimes even very good developers don’t know how to do that. In short, impersonation element in web.config does the trick. If you know the rest, that’s it, you don’t need the rest of this post.
Otherwise, let’s just go through the process. First, go to your IIS folder, usually C:\Inetpub\wwwroot, and create a folder for your application/webservice, say C:\Inetpub\wwwroot\Hello. You can do that in Windows Explorer. I will show an example with webservice,
In this folder you will need two files: web.config and Hello.asmx (assuming you want to call your webservice Hello).
Simple web.config looks like that:
<?xml version=”1.0″?>
<configuration xmlns=”http://schemas.microsoft.com/.NetConfiguration/v2.0″>
<appSettings/>
<connectionStrings/>
<system.web>
<customErrors mode=”Off” />
<compilation debug=”true” defaultLanguage=”c#” />
</system.web>
</configuration>
I have added debugging and set default language to C#, but that’s optional. Hello.asmx file is very simple:
<%@ WebService Language=”C#” CodeBehind=”~/App_Code/Hello.cs” Class=”Hello” %>
Now, create a folder App_Code (C:\Inetpub\wwwroot\Hello\App_Code), that’s where the actual code traditionally lives, and create Hello.cs file, already referenced in Hello.asmx:
using System;
using System.Web;
using System.Web.Services;
using System.Web.Services.Protocols;
[WebService(Namespace = “http://hellomedear.org/test/namespace/”)]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Hello : System.Web.Services.WebService
{
public Hello () {
}
[WebMethod]
public string HelloMeDear()
{
return “Hello, ” + System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString() + “!”;
}
}
This way it will return back the name of the current user, so we can track our progress. So, are we ready? Let’s try. Enter address http://yourmachine/hellome/hello.asmx in the browser. Oops… Error:
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not create type ‘Hello’.
Source Error:
Line 1: <%@ WebService Language=”C#” CodeBehind=”~/App_Code/Hello.cs” Class=”Hello” %> |
Source File: /hellome/hello.asmx Line: 1
Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.42
Why? You forgot to tell IIS that there will be ASP.Net code in this folder. Go to Control Panel | Administrative Tools | Internet Information Services, then select default web site, open it and you’ll see your folder shown with a folder icon. Right-click on it, select Properties, and click on “Create” button near the grayed textbox Application name. The click OK, and the icon will become something mechanical. That’s what you want.
Try again. Now you should get the list of available methods, which in our case is simply HelloMeDear. Click on it, and if you do that from the same machine, you will see a button Invoke, which let’s you try the method.
Click on it. A new windows will open with the result:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<string xmlns=”http://hellomedear.org/test/namespace/“>Hello, NT AUTHORITY\NETWORK SERVICE!</string>
That’s nice, but NT AUTHORITY\NETWORK SERVICE is not your ID. What happened?
Go again into properties of your folder in IIS management, pick Directory Security tab, and press Edit for Authentication and access control. See “Enable anonymous access” checked? That’s the problem. Even if you’ll get impersonation, it will be that automatic user marked in the textboxes next to it. Actually, let’s try it.
Go to your folder and open web.config file. First add
<identity impersonate=”true” />
into <system.web> element. Try again:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<string xmlns=”http://hellomedear.org/test/namespace/“>Hello, YOURMACHINE\IUSR_ YOURMACHINE!</string>
You’ve got that impersonated user. To avoid that, go again into IIS configuration for your folder, Directory Security, edit Authentication and access control, and uncheck Enable anonymous access, plus check checkbox Integrated Windows authentication. Try now:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<string xmlns=”http://hellomedear.org/test/namespace/“>Hello, YOURMACHINE\yourID!</string>
You’ve got it! Actually, it’s nice to add also:
<authentication mode=”Windows”/>
into your web.config file along with impersonation element. That’s it.
So, all steps in a short list:
Source: EDI Subsystem
Category: BizTalk Server 2006
Error encountered: ERROR (120) :
An error occurred in the File System connector. Check the details.Cant make a connection to \\MyComputer\EDIDocsHome\Documents\PickupEDI. Errormessage: The operation cannot be performed because a network component is not started or because a specified name cannot be used.
Check the Security Setting for the file share “\\MyComputer\EDIDocsHome\Documents\PickupEDI”
Make sure “EDI Subsystem Users” group has Full Control to the share.
By default, it is located @ C:\Documents and Settings\All Users\Application Data\Microsoft\BizTalk Server 2006\EDI\SubSystem