The thing to note here is that though the 64-bit editions of Microsoft SQL Server 2005 include Integration Services, some Integration Services features are available only in 32-bit versions, or have limitations on 64-bit computers. For one thing, the ODBC, OLEDB and drivers for Office 12 files have a different 64-bit version. So, if you have tested your SSIS packages (and the connection managers there-in) on a 32-bit machine, they might not behave similarly on 64-bit machine. 

For the SSIS packages that really don't make use of the 64-bit processor, the SSIS project property Run64BitRuntime can be set to False. This is a instruction to load 32-bit runtime environment rather than 64-bit, and your packages would still run without doing any plumbing work. The property can be found under SSIS Project Property Pages -> Configuration Properties -> Debugging.

You can find more information on 64-bit Integration Services considerations here

All right!! So I have created a WCF service and I want to consume it…what do I do? Where do I host the service? The first choice that comes to one’s mind (and which most of the examples talk about) is creating a console application and hosting the WCF service within this application. But this option is good only when you want to host the service quickly and test it out. In a practical scenario, we would require a service which sits there and is available all the time and allows a message based activation. Also, wouldn’t it be great if we can get rid of the extra code that we have to write just to host the service? Fortunately, WCF provides various options when it comes to hosting a service. These options are:

1.       Console application

2.       Winform application

3.       IIS

4.       Windows service

5.       Windows Activation Service.

Of course, the choice of the host restricts the type of transport that you can use for that service. I will not go into those details in this post. Let us look at how we can host the WCF service in IIS. When we use IIS to host WCF services, the services are integrated into ASP .NET. Thus the WCF services can take advantage of some of the inherent feature of ASP .NET such as process recycling, process health monitoring, message-based activation and idle shutdown. So let us get started…

Create a WCF service

1.       Create a blank solution and add a WCF Service Library project to it. For the purpose of this post, I am going to create a simple GreetingService that has a method Greet. This method accepts a single parameter name and returns a string “Hello “ appended to name

2.       The following is the code for the GreetingService WCF service. We define a service contract, mark the operations in that contract that are going to be exposed to the external world and then implement the service.

using System;

using System.Collections.Generic;

using System.Text;

using System.ServiceModel;

namespace Wcf.Samples.ServiceLibrary

{

    [ServiceContract()]

    public interface IGreeting

    {

        [OperationContract()]

        string Greet(string name);

    }

}

GreetingService.cs

using System;

using System.Collections.Generic;

using System.Text;

namespace Wcf.Samples.ServiceLibrary

{

    public class GreetingService : IGreeting

    {

        #region IGreeting Members

        public string Greet(string name)

        {

            return "Hello - " + name;

        }

        #endregion

    }

}

3.       Now that you added the service contract and its implementation (the GreetingService), build the project.

Host the service in IIS

1.       Now we create a Web site that will host the WCF service that we created in the previous section. For this, right-click the solution in the solution explorer and from the context menu, select Add -> New Web site  ->WCF Service as shown in the following figure.

2.       This will create a WCF Service Web site into your solution along with the standard folders that get created for a Web site project (App_Code, App_Data etc). A new type of file called Service.svc will be generated and placed into the root of the Web site project, along with the corresponding code-behind file (Service.cs). The Service.cs is provided to implement a WCF service, which then can be referred in the Service.svc file. Since we already have created the WCF service in a separate assembly, we will refer to it in the Service.svc. As such we don’t need Service.cs and hence, it can be deleted.

3.       Open Service.svc file and modify the single line in it like this:

<%@ ServiceHost Language="C#" Debug="true" Service="Wcf.Samples.ServiceLibrary.GreetingService" %>

4.       In the above statement we point to the fully-qualified class name that implements the service that we want to host in IIS.

5.       Add the reference of the Wcf.Samples.ServiceLibrary project to the web-site project and build the web-site.

6.       This completes the creation of WCF service. Now, in order to let the service communicate with the external world, we need to define the communication behavior of the service. For defining this behavior, we will use the Service Configuration tool that comes along with Visual Studio 2005.

7.       From the main menu of Visual Studio 2005, select Tools -> WCF Service Configuration Editor. The WCF Configuration Editor window will open up. Select File -> Open -> Config File… from the main menu. Browse and select the Web.config file of the WCF web-site.

8.       Once selected, the screen will be displayed as follows. The Web.config already has the configuration for the default service MyService under the Services node in the left-panel. Select this service and deleted it. We are going to create a new configuration for our service.

9.       Right-click the Services node and select “New service” from the context menu. A service with service type NewServiceType will be created. On the right-panel, select the property “Name” and click the ellipsis. Service Type Browser will open up. Browse the bin folder of the web-site and locate the service assembly Wcf.Samples.ServiceLibrary and double-click it. The Service Type Browser dialog now will list the service “Wcf.Samples.ServiceLibrary.GreetingService” service. Select this service and click Open. This will set the service-type that we are going to configure.

10.   Now for the above service, we first need to specify the end-point. Right-click Endpoints node in the left-panel of the WCF Service Configuration Editor and select “New Endpoint”. This will create a default end-point with its properties being displayed in the right-panel.

11.   Set the following properties:

12.   This sets the basic communication for our service. In order to enable the service for metadata exchange (thereby allowing us the browse its wsdl), we need to set the metadata exchange properties for the service. To do this, expand the Advanced node in the left-panel, right-click Service Behaviors and select “New Service Behavior Configuration”. This will add a new Behavior Configuration by the default name NewBehavior. Behavior is a collection of attributes (here, service attributes) that can be set and applied to the service together. Right now, we are going to define a behavior that allows the metadata exchange on the service. Set the Name property of the new behavior configuration to mexBehavior.

13.   In the “Behavior element extension position” (lower part of the right-panel), click “Add” button. This opens up a dialog “Adding Behavior Element Extension Sections”. Select serviceMetadata from the list and click “Add” on the dialog. This adds the extension serviceMetadata to the grid in the right-panel. Double-click the extension to open up its property-page. Set the property HttpGetEnabled to true.

14.   Now that we have defined the behavior separately, we need to associate the behavior with our service. To do this, select the Wcf.Samples.ServiceLibrary.GreetingService under the Services node in the left panel. The right-panel will display its properties. Select the BehaviorConfiguration property, and select “mexBehavior” from the drop-down.

15.   This sets the service configuration and allows the service to communicate with the external world. Save the configuration by selecting the menu File->Save. Close the WCF Service Configuration Editor.

16.   Test that the service is hosted by running the WCF Web Site application. The following screen should be displayed.

You can test this service by creating a Console application and adding a proxy (generate the proxy by running the svcutil.exe utility). In the next post, I will explain how to invoke a WCF service hosted in IIS through the new WCF Adapter in BizTalk R2.

Till then… happy coding J

Consider the following input XML message:

<ns0:Input xmlns:ns0="https://MyProject.MyMessages.Input">

    <Header>

        <FTPServer>MyServer.com</FTPServer>

        <UserName>Foo</UserName>

        <Password>Boo</Password>

        <RetryAttempts>5</RetryAttempts>

        <RetryInterval>10</RetryInterval>

<FileName>OutputMessage.xml</FileName>

     </Header>

    <Body>

        <Content>This is the actual content</Content>    

     </Body>

</ns0:Input>

Let us assume that this message would be transformed into output message like this using a map:

<ns0:Output xmlns:ns0="https://MyProject.MyMessages.Input">

    <Body>

        <Content>This is the actual content</Content>    

     </Body>

</ns0:Output>

In order to send this output message through a dynamic send port, following needs to be done:

1. Verify that the input message has all of its properties that are required to configure the dynamic send port are promoted.
2. Configure a receive location to accept this message. Specify the default XmlReceivePipeline since we are not going to act upon the message and modify its contents before it comes to messagebox.
3. Create an orchestration and specify the Receive shape and set its properties such that it receives the message of type Input.
4. Add a send port to the orchestration with the port binding as dynamic. Name the send port oprtSendDynamic.
5. Next, add a Transform shape and specify the map for this shape that would transform the Input to Output.
6. In the Construct Message shape surrounding t he Transform shape, add a Message Assignment shape below Transform. In the Message Assignment shape, we will configure the properties of the dynamic send port.

msgOutput.Body.Content = msInput.Body.Content

//Set the FTP properties from the input message content

oprtSendDynamic(Microsoft.XLNAGs.BaseTypes.Address) =

"ftp://" + msgInput.Header.FTPServer + "/" + msgInput.Header.FileName;

//Set other FTP properties by tapping the input message as above.

.....

7. Complete the orchestration, bind the ports and test.

A Receive Port is a LOGICAL container for the receive locations. Receive Locations that the ones where one specifies the details about the transport to be used, the exact address where the message is to be delivered and any other specific properties particular to that transport type. Consider, for example, various suppliers sending their Purchase Orders (PO) to your organization. Every supplier would prefer his own method of transmitting his PO across to you, some would do it using file transfer over FTP, others would prefer to do a HTTP post etc. Each of these various types, would then require a receive location on the BizTalk Server, where the server can accept these messages. Each receive location would have configuration specific to its transport-type. Now, since these locations are accepting a conceptually same message i.e. PO, they can be grouped into an additional logical layer called Receive Port. So what do I gain by adding additional layer over the receive locations? BizTalk allows you to specify message authentication, tracking and other properties that are related to PO message as such (and not dependant on the way that message is received). Besides this, there are several other advantages of Receive Ports that are listed below.

1. Suppose you receive PO from ten different suppliers and assume that one of the suppliers is using a format that is different from the rest. The Receive Port allows us to specify the map that allows us to transform the inbound message to a required format before it is submitted to the MessageBox. Thus we can avoid use of orchestration and maybe some complicated logic / conditional branching just so that we transform the message in one particular case.
2. The Orchestrations in BizTalk have a visibility till the Receive Ports. The receive locations are not visible to the orchestrations. This abstracts the orchestrations from the details of specific protocols and locations. Therefore, we can accept conceptually same messages from variety of locations and still treat them in the same way inside an orchestration.

Hope the information helps in understanding the Receive Ports and Receive Locations more clearly.

HTTP could not register URL https://+:8000/. Your process does not have access rights to this namespace (see https://go.microsoft.com/fwlink/?LinkId=70353 for details).

The error occurs due to the new security settings in Windows Vista. Most people are no longer going to be running with Administrator privileges by default like they were doing on earlier platforms. This impacts your ability to run HTTP web services because listening at a particular HTTP address is a restricted operation. By default, every HTTP path is reserved for use by the system administrator. Your services will fail to start with an AddressAccessDeniedException if you aren't running the service from an elevated account. The account under which the Visual Studio and the debugger runs does not have the privilege (though the user account under which VS is runnig may be a part of Administrators group), and hence the error occurs. The plus sign in the URL just means that there's a wildcard being applied to the hostname.

To fix this problem, the owner of the HTTP namespace (built-in administrator) needs to delegate this ownership to the user account under which you are running your application (most of the times, it's the logged on user). To do this, start a command prompt using "Run as administrator" so that you have elevated privileges. Then, use netsh.exe to give some of the Administrator's HTTP namespace to your user account. You can look at the existing HTTP namespace delegations by using "netsh http show urlacl".

Now, use "netsh http add urlacl url=https://+:8000/ user=DOMAIN\UserName" to assign the HTTP namespace to required user account. You can get the syntax for all of these commands by running "netsh http" without any arguments. Note that I've matched the URL in this command to the URL that appeared in the error message. The wildcarding is important for getting the right reservation and you'll continue to be denied access if your reservation covers less than your service's attempted registration. Go back to Visual Studio and check that your service runs properly.