Quantcast
Channel: Adapters – SANDRO PEREIRA BIZTALK BLOG
Viewing all 47 articles
Browse latest View live

BizTalk Adapter – Dynamics CRM 4.0 Adapter Updated – Support BizTalk Server 2009

$
0
0

Overview

Microsoft® BizTalk® Server Adapter for Microsoft Dynamics® CRM 4.0 enables integration between Microsoft Dynamics CRM 4.0 and other business applications. This lets you do the following operations:

  1. Use Microsoft Dynamics CRM as a send adapter.
  2. Discover and use the schema of any Microsoft Dynamics CRM actions and entities.

With the adapter you can integrate Microsoft Dynamics CRM 4.0 with any other business application using the Microsoft BizTalk Server 2006 or Microsoft BizTalk Server 2009 mapping capabilities.

In response to the BizTalk Server 2009 release in the beginner of this year, Dynamic CRM 4.0 Adapter was updated to support

  • Supports both 32-bit and 64-bit deployments of Microsoft Dynamics CRM 4.0
  • Supports form-based authentication
  • Supports multi-tenancy
  • BizTalk Server 2006
  • BizTalk Server 2006 R2
  • BizTalk Server 2009

Link: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=abd3bb9e-a59a-4eb6-8de8-fb25b77926d7

Tags: BizTalk | Adapter | CRM



BizTalk 2009 64 bits Adapters – WCF SAP Adapter – Troubleshooting Installation Issues – Missing sapBinding

$
0
0

I recently have my second bad experience in installing/configuring adapters in 64 bits platform :( .

I installed, with success, the 64bits version of the BizTalk Adapter Pack 2.0, that contain:

  • Microsoft BizTalk Adapter for SQL Server. The Microsoft BizTalk Adapter for SQL Server exposes the SQL Server database as a WCF service. Adapter clients can perform operations on the SQL Server database artifacts such as tables, views, and procedures by exchanging SOAP messages with the adapter Supported SQL Server versions are SQL Server 2000, SQL Server 2005 and SQL Server 2008 The SQL adapter uses ADO.NET to communicate with the SQL Server database. The minimum requirement is .NET 3.5 SP1
  • Microsoft BizTalk Adapter 3.0 for Oracle Database. This Oracle database adapter enables adapter clients to read and write to and Oracle database-
  • Microsoft BizTalk Adapter for Oracle E-Business Suite. Using this adapter clients can perform operations on the the Oracle E-Business Suite artifacts (PL/SQL APIs, interface tables/views, concurrent programs, and request sets) and the underlying Oracle database artifacts (such as tables, functions, and procedures) by exchanging SOAP messages with the adapter.
  • Microsoft BizTalk Adapter 3.0 for mySAP Business Suite. This adapter enables clients to exchange Intermediate Document (IDOC), BAPI, and Remote Function Call (RFC) messages with the SAP system.
  • Microsoft BizTalk Adapter 3.0 for Siebel eBusiness Applications – This adapter enables clients to invoke Business Services and operations on Business Components in a Siebel eBusiness Application.

Problem:

Like I saw before, I installed, with success, the 64bits version of the BizTalk Adapter Pack 2.0, but when I tried to create a new SAP send port in BizTalk Administration Console:

  • In the received location:
    • Use the Custom WCF Adapter
    • Clicked on the “Binding” tab and select sapBinding

I cannot see sapBinding registered in the list of the “Binding” tab.

So why I cannot found sapBinding?

Cause:

The SAP adapter is a WCF custom binding, which is registered under System.ServiceModel in the machine.config file.

A 64-bit platform has two machine.config files, one used by the 32-bit applications and the other used by the 64-bit applications. So, when you install the 64-bit version of the BizTalk Adapter Pack, the setup wizard registers the bindings in the 64-bit version of the machine.config file.

However, Visual Studio runs as a 32-bit process and hence when you launch the Consume Adapter Service Add-in from Visual Studio, the plug-in checks for the bindings in the 32-bit version of the machine.config file and fails giving an error.

Like Visual Studio, BizTalk Admin Console runs as a 32 bit process as well which explains why the Adapter is not visible inside the console, it checks for the bindings in the 32-bit version of the machine.config.

Resolution:

Install both the 32-bit and 64-bit versions of the BizTalk Adapter Pack on a 64-bit WCF LOB Adapter SDK installation.

NOTE: You must only have a 64-bit WCF LOB Adapter SDK installation. Side-by-side installation of 32-bit and 64-bit WCF LOB Adapter SDK on a single computer is not supported.

This problem and resolution applies to the SQL Adapter as well.

Here some good related articles:

Tags: BizTalk | Adapters | Errors and Warnings, Causes and Solutions


Internal SOAP Processing Failure

$
0
0

Recently I try to invoke an orchestration publish as Web Service and I received the following error:

“Internal SOAP Processing Failure” error.

SOLUTION

  • Find out the identity under which the application pool is running.
  • Add this user to both “IIS_WPG” and “BizTalk Isolated Host Users” groups.
  • Check the permission of %temp% folder. Make sure either the user running the application pool or the groups this user belongs to has read/write permission on %temp% folder.

Tags: BizTalk | Web Service | SOAP Adapter


The Messaging Engine failed to register an adapter: SOAP, WCF-BasicHttp, HTTP, …

$
0
0

Problem

The following error may occur when BizTalk Server attempts to register the SOAP, HTTP, or WCF adapter.

“The Messaging Engine failed to register an adapter “SOAP”. Details:
“Registering multiple adapter types within the same process is not a supported scenario. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process”.

“The Messaging Engine failed to register an adapter “HTTP”. Details:
“Registering multiple adapter types within the same process is not a supported scenario. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process”.

or

“The Messaging Engine failed to register an adapter “WCF-BasicHttp”. Details:
“Registering multiple adapter types within the same process is not a supported configuration. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process”.

Potential Causes

  • Already have a different adapter type loaded into IIS, Adapter binding types do not match Receive location for address“/MyService.WCF/MyService.svc” not found. (The BizTalk receive location may be disabled.)
  • Receive location disabled, Typo in Receive Location name

When running BizTalk Server on Windows Server 2003 / IIS 6.x, the SOAP and HTTP adapters cannot execute in the same process space or application pool.


SOLUTION

If an installation requires using the SOAP, HTTP or WCF adapters on the same Web server then separate application pools must be created for each adapter. Once created, the virtual directories for each adapter are each assigned to a different application pool.


We have to separate the receive locations from different adapters in different IIS application pools.

Tags: BizTalk | IIS | SOAP | HTTP | WCF | Adapter


BizTalk WCF Adapter – BasicHttpBinding results in Partial Trust Exception

$
0
0

Exception: System.ServiceModel.ServiceActivationException: The service ‘/MyService/Service.svc’ cannot be activated due to an exception during compilation. The exception message is: That assembly does not allow partially trusted callers.. —> System.Security.SecurityException: That assembly does not allow partially trusted callers.

SOLUTION

After some research I found that I’m getting problem because the WCF service requires full trust permission to run from the server. One way to solve the problem is:

  • Open web.config file in notepad
  • In <system.web> section add the following tag:
    • <trust level="Full" originUrl=""/>
      

These steps solved my problem.

Tags: BizTalk | WCF | Adapters | Errors and Warnings, Causes and Solutions


BizTalk SOAP, HTTP, and HTTP-based WCF Adapters – How many Concurrent Connections are configured by default and how can we change this behavior

$
0
0

By default the SOAP, HTTP, and HTTP-based WCF adapters (and .NET in general) open only two concurrent HTTP connections from each BizTalk server to any specific destination server.

For example, if you have a SOAP send port sending messages to http://www.contoso.com/SomeWebService.asmx, then by default each BizTalk server will open only two concurrent HTTP connections to http://www.contoso.com, no matter how many messages need to be sent.

This setting conforms to the IETF RFC for the HTTP 1.1 specification, and although it is suitable for user scenarios it is not optimized for high throughput.

Incresing the Number of Concurrent Connnections

To increase the number of concurrent connections, you can modify the entry in the BizTalk Server configuration file, BTSNTSvc.exe.config (or BTSNTSvc64.exe.config for 64-bit hosts), on each BizTalk server. You can increase this for the specific servers being called.

The following is an example of the configuration for the maximum connections property:

<configuration>
   <system.net>
      <connectionManagement>
         <add address=" http://www.contoso.com" maxconnection="20" />
         <add address = "http://www.northwind.com" maxconnection = "2" />
         <add address="*" maxconnection="10" />
      </connectionManagement>
   </system.net>
</configuration>

In this sample we are saying that:

  • The endpoint contoso is configured with 20 concurrent connections
  • The endpoint northwing is configured with 2 concurrent connections
  • And the remaining are configured with 10 concurrent connections (change the default value)

Note:

Do not increase the value for the maxconnection parameter to such a large value that the Web server being called is overwhelmed with HTTP connections. Perform stress testing by sending requests to each destination Web server to determine a value for maxconnection that will provide good without overwhelming the target Web servers.

The default value for the “maxconnnection” property is 2, the maximum value that can be set for the “maxconnection” property for all URIs is 20.

Other considerations:

The “maxconnnection” property has no effect on the connection limit for making calls to local web services. Therefore, local web services always tend to give preference to the requests that come from the local computer over requests that come from other machines. This degrades the throughput of the web service for remote clients.

If the local web services are not making calls to any external systems and their web method processing time is considerably low, package them into a .NET library and call them from within your orchestrations. If those web services are calling external systems or take a considerable amount of processing time, move them off the BizTalk Server Group servers.

Related links

(this post is mainly for personal tracking, sorry for the duplicate content)

Tags: BizTalk | SOAP | HTTP | WCF | Adapters | Configurations


New version of BizTalk Scheduled Task Adapter is now available on CodePlex

$
0
0

First of all I would like to thank Greg Forsythe for their kindness and for added me as coordinator on this project.

In the past weeks I have been working on this new version of this adapter, mostly making small improvements and documentation, and now I can say… A new version of BizTalk Scheduled Task Adapter is available for download on CodePlex:

codeplex-BizTalk-Scheduled-Task-Adapter-page

Requirements

This adapter was tested to work on BizTalk Server 2010. Compiled in .NET Framework 4.0

The Scheduled Task Adapter v4.0 will work with:

  • BizTalk Server 2010
  • .NET Framework 4.0

List of improvements in version 4.0

  • In this new version are available small improvements compared to the current version (3.0). We can highlight the following improvements or changes:
  • 24 hours support in “start time” property. Previous versions had an issue with setting the start time, as it shown 12 hours watch but no AM/PM.
  • Daily scheduler review. Solved a small bug on Daily Properties: unable to switch between “Every day” and “on these days”
  • Installation experience improved. You no longer need to manually add the DLL in GAC.
  • Support for 32 and 64 bit Host Instances.
  • Compiled in Visual Studio 2010 and .NET Framework 4.0.
  • Optimized for BizTalk Server 2010.
  • Documentation improved.

BizTalk Scheduled Task Adapter v4.0 (1428.0 KB)
CodePlex


BizTalk Scheduled Task Adapter 4.0: Introduction and Installation process

$
0
0
Introduction

The BizTalk Scheduled Task Adapter is an in-process receive adapter that executes a prescribed task on a daily, weekly or monthly schedule. The adapter is configured entirely within BizTalk, all configurations is stored within the SSODB and can be exported and imported via binding files.

The schedule capabilities are similar to those available with the Windows Scheduled Task Service.

Four simple tasks are included in this version:

  • XmlStringStreamProvider – generates a BizTalk message from a configured Xml string
  • FileStreamProvider – generates a BizTalk message from the contents of a file
  • HttpDownload – generates a BizTalk message from data downloaded from a web site
  • SQLStreamProvider – generates a BizTalk message from the contents of a SQL Query (similar to the old SQL adapter)

Custom tasks can be created. Any .NET class that implements the appropriate interface can be scheduled.

Release History

This adapter is available since BizTalk Server 2004.

  • Release 1.02: last release in Apr 20 2008 by Greg Forsythe, this adapter works with BizTalk Server 2004, BizTalk Server 2006 and BizTalk Server 2006 R2. Compiled in .NET Framework 1.1
  • Release 2.0: last release in Apr 20 2008 by Greg Forsythe, this adapter works with BizTalk Server 2006 and BizTalk Server 2006 R2. Compiled in .NET Framework 2.0
  • Release 3.0: release in Aug 10 2010 by Greg Forsythe, this adapter was tested to work on BizTalk Server 2009. Compiled in .NET Framework 2.0
  • Release 4.0: release in June 12 2012 by Sandro Pereira, this adapter was tested to work on BizTalk Server 2010. Compiled in .NET Framework 4.0
Requirements

The Scheduled Task Adapter v4.0 will work with:

  • BizTalk Server 2010
  • .NET Framework 4.0

 

Installation Process

To install the adapter run "ScheduledTaskAdapter.msi".

  • In the “Welcome” screen press “Next”.

Scheduler-Task-Adapter-welcome-screen

  • In the “Select Installation Folder” screen you must set the installation locations were you what to install the adapter.

Scheduler-Task-Adapter-installation-folder-screen

  • The following screens are very straightforward – In the “Confirm Installation” screen press “Next”, then it will appear the installation progress and assuming all goes well a completion screen.

Scheduler-Task-Adapter-confirmation-screen

Scheduler-Task-Adapter-complete-screen

The setup will install the following assemblies in the selected folder (Default: C:\Program Files (x86)\Biztalk ScheduledTask Adapter):

  • Biztalk.Adapter.ScheduledTaskProperties.dll
  • Calendar.Schedules.dll
  • Microsoft.BizTalk.CommonSettings.dll
  • Microsoft.BizTalk.SqmFramework.dll
  • ScheduledTaskAdapter.Admin.dll
  • ScheduledTaskAdapter.dll
  • ScheduledTaskAdapter.TaskComponents.dll
  • stdole.dll

The setup will add the following assemblies to the Global Assembly Cache (GAC)

  • Biztalk.Adapter.ScheduledTaskProperties.dll
  • Calendar.Schedules.dll
  • ScheduledTaskAdapter.dll
  • ScheduledTaskAdapter.Admin.dll
  • ScheduledTaskAdapter.TaskComponents.dll

 

Post-Installation
Register the Adapter with BizTalk

As it happens with all adapters that we installed on our BizTalk Servers before we can begin to use it we need to register or configure the adapter. To accomplish that we need to:

  • Open BizTalk Administration Console
  • In the console left tree, expand “BizTalk Server Administration –> BizTalk Group –> Platform Settings” and then “Adapters”
  • Right-click on “Adapters” and add a new adapter by selecting the option “New –> Adapter”

register-Scheduler.Task-Adapter-New-Adapter

  • In the “Adapter Properties” window
    • Set the name of the adapter: Name = Schedule
    • In the adapter combo box select the option: Schedule
    • Set the description of the adapter: “BizTalk Scheduled Task Adapter. The schedule capabilities are similar to those available with the Windows Scheduled Task Service.” (this property is optional but I would suggest to always be filled)

register-Scheduler.Task-Adapter-New-Adapter-select-adapter-properties

Note: This configuration requires that you restart the host instance associated with the adapter.

register-Scheduler.Task-Adapter-New-Adapter-restart-host-instances

Using the adapter Context Properties

To utilize the Scheduled Task adapter’s context properties within a filter or orchestration the Biztalk.Adapter.ScheduledTaskProperties.dll must be deployed into the BizTalkMgmtDb.

This can be achieved using the Biztalk Deployment Wizard or equivalent tool.

Note: This step is optional; you only need to do this if you want to use Scheduled Task adapter’s context properties within a filter or orchestration.

As previously mentioned, you can deploy Biztalk.Adapter.ScheduledTaskProperties.dll in various ways; I suggest that you do the following steps:

  • Open BizTalk Administration Console
  • In the console left tree, expand “BizTalk Server Administration –> BizTalk Group” and then “Applications”
  • Right-click on “Applications” and add a new application by selecting the option “New –> Application”

New-application

  • In the “Adapter Properties” window
    • Set the name of the application: BizTalk.Global
    • Set the description of the application: “Application that contain common resources to several applications” (this property is optional but I would suggest to always be filled)

New-application-properties

  • Expand the application created previous and select the option “Resources”
  • Right-click and add a new BizTalk resource by selecting the option “New –> BizTalk Assemblies…”

New-resource

  • In the “Add Resources” window select “Add…” button and from the installation directory select the DLL “Biztalk.Adapter.ScheduledTaskProperties.dll”
    • And select the options: “Overwrite all”, “Add to the global assembly cache on add resource (gacutil)” and “Add to the global assembly cache on MSI file install (gacutil)”

New-resource-dll

  • Select “OK” button

Important note: The BizTalk assembly containing the orchestration code must also add this assembly as a reference

List of improvements in version 4.0

In this new version are available small improvements compared to the current version (3.0). We can highlight the following improvements or changes:

  • 24 hours support in “start time” property. Previous versions had an issue with setting the start time, as it shown 12 hours watch but no AM/PM.
  • Daily scheduler review. Solved a small bug on Daily Properties: unable to switch between “Every day” and “on these days”
  • Installation experience improved. You no longer need to manually add the DLL in GAC.
  • Support for 32 and 64 bit Host Instances.
  • Compiled in Visual Studio 2010 and .NET Framework 4.0.
  • Optimized for BizTalk Server 2010.
  • Documentation improved.


List of open source projects for BizTalk developers

$
0
0

For some time that I didn’t contribute to new articles on TechNet Wiki, only having systematically adding new errors in the article BizTalk: List of Errors and Warnings, Causes and Solutions

There are a number of open source projects: pipelines, adapters and functoids that can aid you as BizTalk developer. These resources are not the out of the box offered by BizTalk Server like WCF Publishing Wizard or BizTalk Server Adapter pack (that provides connectivity to SAP, Siebel, SQL and many more).

Through the internet you can find numerous open source projects created by people from community, Microsoft, Microsoft Community Contributors (MCC) and Microsoft® Most Valuable Professionals (MVP), which can help you speeding up the development process of our projects.

We can find in TechNet Wiki three articles describing a list of several projects:


New minor release of BizTalk Scheduled Task Adapter for BizTalk Server 2010 is now available

$
0
0

Finally I had some free time available to be able to update and fix some minor bugs which existed in the latest version of this adapter and already had been reported by community members.

I have to give a special thanks to maakku that reported a problem related to the Daily schedule properties… and the respective solution!!

So today a published a minor release of BizTalk Scheduled Task Adapter is available for download on CodePlex: BizTalk Scheduled Task Adapter v4.0

NOTE: the adapter is still in version 4.0, I have not modified the version. As I said earlier this is a minor release to solved small bugs.

codeplex-BizTalk-Scheduled-Task-Adapter-page

List of improvements in this minor release:

  • Daily scheduler review. Solved a small bug on Daily Properties: settings were not saved correctly when configuring daily schedule in admin console (see more here)
  • Support for 32 and 64 bit Host Instances.
  • Fix the version number of the adapter that was being recorded incorrectly as 3.0.0. After installing the adapter, in Programs and Features the version for the BizTalk Scheduled Task Adapter it was 3.0.0.

Note: The adapter was tested with success running in 32 and 64 bit Host Instances!


PowerShell to Configure BizTalk Server Host and Host Instances according to some of the Best Practices

$
0
0

Personally I like to create all my BizTalk Server installation and configuration process manually at least one time or maybe from time to time, but when we are dealing with several environments and even worse each environment with several BizTalk Servers… this can be very annoying and time consuming. In this case automation is the key!

One of the task that we need to do in all our new BizTalk environment over and over again is creating and configuring the Host, Host Instances and of course the adapter handlers.

What’s is Host, Host Instances and Adapter Handlers?

The BizTalk Host is a logical process and security boundary within BizTalk Server that represents a logical set of zero or more run-time processes in which you can deploy BizTalk Server services and artifacts (such as adapter handlers, receive locations, and orchestrations). Each host has a security group assigned to it and may contain multiple host instances, each on an individual machine, that perform the work of the host.

In turn, a host instance is the physical instance of a host on a computer running BizTalk Server. Each host instance belongs to exactly one host, and the service account of the host instance belongs to the security group of the host. The security group may be used to grant permissions to physical resources such as databases for use by any host instances in the host.

An adapter handler is an instance of a BizTalk host in which the adapter code runs. When you specify a send or receive handler for an adapter you are specifying which host instance the adapter code will run in the context of. An adapter handler is responsible for executing the adapter and contains properties for a specific instance of an adapter. A default BizTalk Server configuration will create adapter handlers for all of the installed adapters, but you may want to create additional adapter handlers for purposes of load balancing or to provide process isolation for a particular adapter handler.

Best practices to Configuring Hosts and Host Instances

As the official documentation specify, in addition to the high availability aspects of the host instance configuration, you should separate sending, receiving, processing, and tracking functionality into multiple hosts. This provides flexibility when configuring the workload in your BizTalk group and is the primary means of distributing processing across a BizTalk group.

This also allows you to stop one host without affecting other hosts. For example, you may want to stop sending messages to let them queue up in the MessageBox database, while still allowing the inbound receiving of messages to occur.

Separating host instances by functionality also provides some of the following benefits:

  • Each host instance has its own set of resources such as memory, handles, and threads in the .NET thread pool.
  • Multiple BizTalk Hosts will also reduce contention on the MessageBox database host queue tables since each host is assigned its own work queue tables in the MessageBox database.
  • Throttling is implemented in BizTalk Server at the host level. This allows you to set different throttling characteristics for each host.
  • Security is implemented at the host level; each host runs under a discrete Windows identity.

However this also may bring some potential drawbacks if too many host instances are created because each host instance is a Windows service (BTSNTSvc.exe or BTSNTSvc64.exe), which generates additional load against the MessageBox database and consumes computer resources (such as CPU, memory, threads), so you need to be careful.

Normally we read that we need to create at least 4 host instances: sending, receiving, processing, and tracking, but that’s not absolutely true because, at least with the newer environments, we typically use 64-bits versions and in this case we also need to create at least one Host Instance that will run on 32-bits because FTP adapter, SQL adapter, POP3 adapter and MIME Decoder on 64-bit host instances is not supported by the product (http://technet.microsoft.com/en-us/library/aa560166.aspx)

We can define that one of the best practices for hosts and host instances is the following:

  • BizTalkServerTrackingHost: A BizTalk Host that hosts tracking is responsible for moving the DTA and BAM tracking data from the MessageBox database to the BizTalk Tracking (DTA) and BAM Primary Import databases. This movement of tracking data has an impact on the performance of other BizTalk artifacts that are running in the same host that is hosting tracking. Thus, you should use a dedicated host that does nothing but host tracking.
    • Only the optionAllow Host Tracking” must be selected because we only will use this host for tracking.
  • BizTalkServerReceiveHost: All options (Allow Host Tracking”, “32-bits only” or “Make this default host in the group”) should be unselected. This host will be responsible for processing messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location (with a pipeline), the message decoding and decrypting occurs in a pipeline within this host.
    • All receive handlers, except the isolated ones like SOAP, HTTP, WCF-BasicHttp, WCF-WsHttp or WCF-CustomIsolated and 32 bit adapters (FTP,SQL and POP3) will be configured for this host. This will mean also that all receive locations will run in this host instance.
  • BizTalkServerReceive32Host: has the same goal as the previous however this must have the “32-bits only” option select so that we can run the 23-bits adapters.
    • The receive handlers for the FTP, SQL and POP3 adapters will be configured for this host.
  • BizTalkServerSendHost: All options (Allow Host Tracking”, “32-bits only” or “Make this default host in the group”) should be unselected. This host will be responsible for processing messages before they are sent out to the send port. When a host contains a sending item, such as a send port, the message signing and encryption occurs in a pipeline within this host.
    • All send handlers, except 32 bit adapters like native SQL and FTP adapter, will be configured for this host. This will mean also that all send ports will run in this host instance.
  • BizTalkServerSend32Host: has the same goal as the previous however this must have the “32-bits only” option select so that we can run the 32-bits adapters.
    • The Send handlers for the FTP and SQL adapters will be configured for this host.
  • BizTalkServerApplication: Only the option32-bits only” should be select in this host. This host will be responsible for process messages based on the instructions in orchestrations that need to run in 32-bits.
  • BizTalkServerApplication64Host: Only the optionMake this default host in the group” should be select in this host. This host will be responsible for process messages based on the instructions in all or most common orchestrations.

Note: You can create other Application Host if you want to separate process base in some application logic.

How can I automate this task?

Windows PowerShell is a Windows command-line shell designed especially for system administrators and can be used by BizTalk administrators to help them in automating tasks.

This is a simple script to configure the Host, Host Instance and Adapter Handlers described earlier in this post:
Function that will create a new BizTalk Host

function CreateBizTalkHost([string]$hostName, [int]$hostType, [string]$ntGroupName, [bool]$authTrusted, [bool]$isTrackingHost, [bool]$is32BitOnly)
{
    try
    {
        [System.Management.ManagementObject]$objHostSetting = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostSetting").CreateInstance()

        $objHostSetting["Name"] = $hostName
        $objHostSetting["HostType"] = $hostType
        $objHostSetting["NTGroupName"] = $ntGroupName
        $objHostSetting["AuthTrusted"] = $authTrusted
        $objHostSetting["IsHost32BitOnly"] = $is32BitOnly
        $objHostSetting["HostTracking"] = $isTrackingHost

        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::CreateOnly;

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objHostSettingType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objHostSettingType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objHostSetting, $putOptions)

		Write-Host "Host $hostName was successfully created" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("Another BizTalk Host with the same name already exists in the BizTalk group.") -eq $true)
        {
			Write-Host "$hostName can't be created because another BizTalk Host with the same name already exists in the BizTalk group." -Fore DarkRed
        }
		else{
        	write-Error "$hostName host could not be created: $_.Exception.ToString()"
		}
    }
}

Function that will update an existent BizTalk Host

function UpdateBizTalkHost([string]$hostName, [int]$hostType, [string]$ntGroupName, [bool]$authTrusted, [bool]$isTrackingHost, [bool]$is32BitOnly, [bool]$isDefaultHost)
{
    try
    {
        [System.Management.ManagementObject]$objHostSetting = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostSetting").CreateInstance()

        $objHostSetting["Name"] = $hostName
        $objHostSetting["HostType"] = $hostType
        $objHostSetting["NTGroupName"] = $ntGroupName
        $objHostSetting["AuthTrusted"] = $authTrusted
        $objHostSetting["IsHost32BitOnly"] = $is32BitOnly
        $objHostSetting["HostTracking"] = $isTrackingHost
		$objHostSetting["IsDefault"] = $isDefaultHost

        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::UpdateOnly; # This tells WMI it's an update.

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objHostSettingType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objHostSettingType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objHostSetting, $putOptions)

		Write-Host "Host $hostName was successfully updated" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
        write-Error "$hostName host could not be updated: $_.Exception.ToString()"
    }
}

Function that will create a new BizTalk Host Instance

function CreateBizTalkHostInstance([string]$hostName, [string]$serverName, [string]$username, [string]$password)
{
    try
    {
        [System.Management.ManagementObject]$objServerHost = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_ServerHost").CreateInstance()

        $objServerHost["HostName"] = $hostName
        $objServerHost["ServerName"] = $serverName
        $objServerHost.Map()

        [System.Management.ManagementObject]$objHostInstance = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostInstance").CreateInstance()

        $name = "Microsoft BizTalk Server " + $hostName + " " + $serverName
        $objHostInstance["Name"] = $name
        $objHostInstance.Install($username, $password, $true)

		Write-Host "HostInstance $hostName was mapped and installed successfully. Mapping created between Host: $hostName and Server: $Server);" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("Another object with the same key properties already exists.") -eq $true)
        {
			Write-Host "$hostName host instance can't be created because another object with the same key properties already exists." -Fore DarkRed
        }
		else{
        	write-Error "$hostName host instance on server $Server could not be created: $_.Exception.ToString()"
		}
    }
}

Function that will delete an existent host handlers in the adapters

function DeleteBizTalkAdapterHandler([string]$adapterName, [string]$direction, [string]$hostName)
{
	try
    {
		if($direction -eq 'Receive')
		{
			[System.Management.ManagementObject]$objHandler = get-wmiobject 'MSBTS_ReceiveHandler' -namespace 'root\MicrosoftBizTalkServer' -filter "HostName='$hostName' AND AdapterName='$adapterName'"
	        $objHandler.Delete()
		}
		else
		{
			[System.Management.ManagementObject]$objHandler = get-wmiobject 'MSBTS_SendHandler2' -namespace 'root\MicrosoftBizTalkServer' -filter "HostName='$hostName' AND AdapterName='$adapterName'"
	        $objHandler.Delete()
		}

		Write-Host "$direction handler for $adapterName / $hostName was successfully deleted" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
        if ($_.Exception.Message -eq "You cannot call a method on a null-valued expression.")
        {
			Write-Host "$adapterName $direction Handler for $hostName does not exist" -Fore DarkRed
        }
        elseif ($_.Exception.Message.IndexOf("Cannot delete a receive handler that is used by") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use and can't be deleted." -Fore DarkRed
        }
		elseif ($_.Exception.Message.IndexOf("Cannot delete a send handler that is used by") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use and can't be deleted." -Fore DarkRed
        }
		elseif ($_.Exception.Message.IndexOf("Cannot delete this object since at least one receive location is associated with it") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use by at least one receive location and can't be deleted." -Fore DarkRed
        }
        else
        {
            write-Error "$adapterName $direction Handler for $hostName could not be deleted: $_.Exception.ToString()"
        }
    }
}

Function that will create a handler for a specific adapter on the host

function CreateBizTalkAdapterHandler([string]$adapterName, [string]$direction, [string]$hostName, [string]$originalDefaulHostName, [boolean]$isDefaultHandler, [boolean]$removeOriginalHostInstance)
{
	if($direction -eq 'Receive')
	{
		[System.Management.ManagementObject]$objAdapterHandler = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_ReceiveHandler").CreateInstance()
		$objAdapterHandler["AdapterName"] = $adapterName
	    $objAdapterHandler["HostName"] = $hostName
	}
	else
	{
		[System.Management.ManagementObject]$objAdapterHandler = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_SendHandler2").CreateInstance()
		$objAdapterHandler["AdapterName"] = $adapterName
	    $objAdapterHandler["HostName"] = $hostName
	    $objAdapterHandler["IsDefault"] = $isDefaultHandler
	}

    try
    {
        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::CreateOnly;

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objAdapterHandlerType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objAdapterHandlerType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objAdapterHandler, $putOptions)

        Write-Host "$adapterName $direction Handler for $hostName was successfully created" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("The specified BizTalk Host is already a receive handler for this adapter.") -eq $true)
        {
			Write-Host "$hostName is already a $direction Handler for $adapterName adapter." -Fore DarkRed
        }
		elseif($_.Exception.Message.Contains("The specified BizTalk Host is already a send handler for this adapter.") -eq $true)
        {
			Write-Host "$hostName is already a $direction Handler for $adapterName adapter." -Fore DarkRed
        }
		else {
        	write-Error "$adapterName $direction Handler for $hostName could not be created: $_.Exception.ToString()"
		}
    }

	if($removeOriginalHostInstance)
	{
		DeleteBizTalkAdapterHandler $adapterName $direction $originalDefaulHostName
	}
}

Function that will have the logic you want to implement to create the default hosts and host instances and add configure the host instances to the various handlers

function ConfiguringBizTalkServerHostAndHostInstances
{
	# Separate sending, receiving, processing, and tracking functionality into multiple hosts.
	# This provides flexibility when configuring the workload and enables you to stop one host without affecting other hosts.
	# you can use a common well use convention to define the name of the host:
	#  - <Job>_<bit support>_<seq>_<adapter/functionality>_<throughput>_<priority>_<clustered>
	# Sample 'Rcv_x32_1_FTP_L_Critical_Clustered'
	# But I will use a more simple convencion
	# Defining the names of the hosts
	[string]$receiveHostName = 'BizTalkServerReceiveHost'
	[string]$sendHostName = 'BizTalkServerSendHost'
	[string]$processingHostName = 'BizTalkServerApplication64Host' # use this to create another processing host
	[string]$trackingHostName = 'BizTalkServerTrackingHost'
	# Note: why we need to create 32bits hosts? FTP, POP3 and SQL doesn't support 64bits
	[string]$receive32HostName = 'BizTalkServerReceive32Host'
	[string]$send32HostName = 'BizTalkServerSend32Host'

	# 'BizTalkServerApplication' is the default host instance created when you install the biztalk on your box.
	# This application will be running on "32-bit only".
	[string]$defaultHostName = 'BizTalkServerApplication'

 	##############################
	# Creating hosts for receiving
	# HostType: Invalid: 0, In-process:	1, Isolated: 2
	CreateBizTalkHost $receiveHostName 1 $ntHostGroupName $false $false $false
	CreateBizTalkHost $receive32HostName 1 $ntHostGroupName $false $false $true

	# Create a host instances for receiving associated with the previous hosts created
	CreateBizTalkHostInstance $receiveHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword
	CreateBizTalkHostInstance $receive32HostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Set adapters that should be handled by receiving host instance
	CreateBizTalkAdapterHandler 'FILE' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MQSeries' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MSMQ' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-Custom' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetMsmq' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetNamedPipe' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetTcp' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'Windows SharePoint Services' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	#32 bits adapters
	CreateBizTalkAdapterHandler 'FTP' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'POP3' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SQL' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler

 	##############################
	# Creating hosts for sending
	# HostType: Invalid: 0, In-process:	1, Isolated: 2
	CreateBizTalkHost $sendHostName 1 $ntHostGroupName $false $false $false
	CreateBizTalkHost $send32HostName 1 $ntHostGroupName $false $false $true

	# Create a host instances for sending associated with the previous hosts created
	CreateBizTalkHostInstance $sendHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword
	CreateBizTalkHostInstance $send32HostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Set adapters that should be handled by sending host instance
	CreateBizTalkAdapterHandler 'FILE' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'HTTP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MQSeries' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MSMQ' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SOAP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SMTP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-BasicHttp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-Custom' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetMsmq' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetNamedPipe' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetTcp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-WSHttp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'Windows SharePoint Services' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	#32 bits adapters
	CreateBizTalkAdapterHandler 'FTP' 'Send' $send32HostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SQL' 'Send' $send32HostName $defaultHostName $true $removeOriginalAdapterHandler

	# Create a host for tracking
	CreateBizTalkHost $trackingHostName 1 $ntHostGroupName $false $true $false

	# Create a host for orchestrations
	CreateBizTalkHost $processingHostName 1 $ntHostGroupName $false $false $false

	# Create a host instance for orchestrations
	CreateBizTalkHostInstance $processingHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Create a host instance for tracking
	CreateBizTalkHostInstance $trackingHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Remove "Allow Host Tracking" options from BizTalkServerApplication Host
	UpdateBizTalkHost $defaultHostName 1 $ntHostGroupName $false $false $true $true

	# Updating the processinh host to be the default host
	UpdateBizTalkHost $processingHostName 1 $ntHostGroupName $false $false $false $true
}

And in the last the main script

Write-Host "Starting configure the BizTalk Server environment..." -Fore DarkGreen

# General variables
# Defining the BizTalk Server Name, this line will read the Server name on which the script is running
$bizTalkServerName = $(Get-WmiObject Win32_Computersystem).name

# STEP 1
# The Windows group is used to control access of a specif host and associated host instances to databases and other
# resources. Each instance of this host must run under a user account that is a member of this group.
# Note that you can change the Windows group only if no instances of this host exist.
# Defining the name of the group the BizTalk hosts should run under
[string]$ntHostGroupName = Read-Host -Prompt "Please enter windows group to control access to Hosts and ssociated Host Instances"

# STEP 2
# This account must have SQL Server permissions. The recommended way to grant these permissions is to add this account
# to the BizTalk Server Host Windows group.
# BizTalk Server will add this account to the "Log on as a service" security policy.
# For domain accounts, use "domain\user" format
# Defining the credentials in witch the host instance should run under.
try
{
	$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
	$domainName = $domain.name
}
catch
{
	$domainName = $(Get-WmiObject Win32_Computersystem).name
}
$hostCredentials = $Host.ui.PromptForCredential("Logon Credentials","This account must have SQL Server permissions. The recommended way to grant these permissions is to add this account to the BizTalk Server Host Windows group.

BizTalk Server will add this account to the 'Log on as a service' security policy", $domainName + "\", "");
[String]$hostCredentialsPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($hostCredentials.Password));

# STEP 3
# Defining the option if you want to automatically try to remove the BizTalkServerApplication Host Instance from
# the Adapters handlers
$windowsShell = new-object -comobject wscript.shell
$questionResult = $windowsShell.popup("Do you want to try to remove the BizTalkServerApplication Host Instance from the Adapters handlers?

Note: The script cannot remove the default host instances if there are any receiveports, sendports or orchestrations configured.",
						  0,"BizTalk Applications, Receive and Send Ports",4)

If ($questionResult -eq 6) {
	$removeOriginalAdapterHandler = $true
}
else {
	$removeOriginalAdapterHandler = $false
}

# STEP 4
# Create default hosts, host instances and handlers
Write-Host "Creating hosts and host instances..." -Fore DarkGreen
ConfiguringBizTalkServerHostAndHostInstances

# STEP 5
# This configurations changes requires host instances restart for the changes to take effect.
# Check if you want to restart the Host Instances
Write-Host "Host and Host Instance configuration is almost completed..." -Fore DarkGreen
$questionResult = $windowsShell.popup("This configurations changes requires host instances restart for the changes to take effect.

Do you want to restart the Host Instances now?", 0,"Please restart Host Instances",4)
If ($questionResult -eq 6) {
	get-service BTS* | foreach-object -process {restart-service $_.Name}
	Write-Host "Restart Host Instance completed..." -Fore DarkGreen
}

# STEP 6
# Check if you want to properly configure BizTalk Services and Enterprise Single Sign-On Service 'Startup type' property
# to Automatic (Delayed Start)
$questionResult = $windowsShell.popup("By default, the 'Startup type' propriety of BizTalk Services and Enterprise Single Sign-On Service are set as 'Automatic', however BizTalk Server services may not start automatically after a system restart, to avoid this behavior you must config the 'Startup type' to 'Automatic (Delayed Start)'.

Do you want to configure BizTalk Services to 'Automatic (Delayed Start)'?", 0,"Configure BizTalk Services to Automatic (Delayed Start)",4)
If ($questionResult -eq 6) {
	#=== Name of the Enterprise Single Sign-On Service. ===#
	$entSSOServiceName = 'ENTSSO'

	#=== Change the startup type for BizTalk services to Automatic (Delayed Start) ===#
	get-service BTSSvc* | foreach-object -process { SC.EXE config $_.Name start= delayed-auto}

	#=== Change the startup type for Enterprise Single Sign-On Service to Automatic (Delayed Start) ===#
	SC.EXE config $entSSOServiceName start= delayed-auto

	Write-Host "BizTalk Services and SSO configured successfully..." -Fore DarkGreen
}

Write-Host "Your BizTalk Server environment is now properly configured" -Fore DarkGreen

The script can be found and download on Microsoft TechNet Gallery:
PowerShell to Configure BizTalk Server Host and Host Instances (7.4 KB)
Microsoft TechNet Gallery


BizTalk Adapter 2.0 for mySAP Business Suite: Error in Check Transaction Failed to load the runtime

$
0
0

This weekend after installing .NET Framework 4.0 in a BizTalk Server 2006 R2 environment, the BizTalk Adapter 2.0 for mySAP Business Suite started to throw the following error when he tried to receive data from the SAP system.

“Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Description: Error in Check Transaction: Failed to load the runtime.
(Exception from HRESULT: 0×80131700)”

BizTalk-Adapter-mySAP-Business-Suite-Transaction-Failed-to-load-the-runtime

CAUSE

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by mySAP Business Suite does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then raise this error.

SOLUTION

You need to manually reregister the sapreceiver.dll (this DLL is usually in this folder: “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\”). To accomplish that you need to:

  • Execute cmd (Start → cmd)
  • Type “cd C:\Windows\Microsoft.NET\Framework\v1.1.4322”
  • And execute the following command to fixed the problem:
    • regasm.exe “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\sapreceiver.dll”

Note: When you install .NET Framework 4.0 in older versions of BizTalk Server like BizTalk Server 2006 or 2006 R2, normally, you will also have problems with the Enterprise Single Sign-On Service for the exact same reasons and the solution is also to manually reregister the DLL but this time the SSOSQL.dll. To find more about this error check: Fixing BizTalk ENTSSO – Could not create SSOSQL. To fix the problem, reinstall SSO or try ‘regasm SSOSQL.dll’ from a Visual Studio command prompt.

References:


BizTalk Scheduled Task Adapter 4.0 is fully compatible with BizTalk Server 2013

$
0
0

I have been receiving a few requests to release a new version of BizTalk Scheduled Task Adapter for BizTalk Server 2013. Actually I am planning a new version of this adapter, of course probably will be optimized for BizTalk Server 2013, but in reality this will not be the main focus.

BizTalk Scheduled Task Adapter Feature Roadmap

Here’s what you can expect to see in BizTalk Scheduled Task Adapter in the next few months:

  • Bring 1 or 2 really new features like JSON or REST support
  • Improve the existing features by solving some minor problems
  • Side-by-side installation
  • Improve documentation

 

But before I begin to develop a new version, I decided to perform a “battery of tests” with the current version of this adapter in order to know if there was any problem or if it was fully compatibility with latest platforms of Microsoft: BizTalk Server 2013, SQL Server 2012 and Windows Server 2012.

The good news is that for now I didn’t detect any kind of problems:

  • I was able to install and configure the adapter on a BizTalk Server 2013 running in a Windows Server 2012 with SQL Server 2012:

Scheduler-Adapter-running-BTS2013

  • And I was able to create a new receive location and specify a scheduler to run the XmlStringStreamProvider to send an XML message every one hour

Scheduler-Adapter-running-BTS2013-add-receive-locationScheduler-Adapter-running-BTS2013-configure-scheduler-receive-location

Scheduler-Adapter-running-BTS2013-configure-scheduler-receive-location-2

I have not done all the tests possible, but I can say that the bases features tested in the latest version of this adapter are fully compatible with BizTalk Server 2013.

If you found any problem running this version in BizTalk Server 2013 or 2010, feel free to email me with your problem or add a comment.


BizTalk Could not load file or assembly ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342′ or one of its dependencies. The system cannot find the file specified.

$
0
0

Recently I work in a project when I need to communicate with Oracle database in which I encountered some platform configuration problems. In general, communicate with Oracle is very simple and somewhat similar to SQL Server.

In development phase I didn’t have any problem, but notice that before you start developing you need to make sure that you have BizTalk Adapter Pack installed and Oracle client (or at least Oracle Data Access Components (ODAC) – 32 and 64 bits) installed to use BizTalk Adapter for Oracle in your BizTalk environment.

The BizTalk Adapter Pack consists of the following adapters:

  • Microsoft BizTalk Adapter for Oracle Database (Oracle Database adapter).
  • Microsoft BizTalk Adapter for Oracle E-Business Suite (Oracle E-Business adapter).
  • Microsoft BizTalk Adapter for mySAP Business Suite (SAP adapter). This also includes the .NET Framework Data Provider for mySAP Business Suite (Data Provider for SAP).
  • Microsoft BizTalk Adapter for Siebel eBusiness Applications (Siebel adapter). This also includes the .NET Framework Data Provider for Siebel eBusiness Applications (Data Provider for Siebel).
  • Microsoft BizTalk Adapter for SQL Server (SQL adapter).

And you can found more information how to install it here: BizTalk 2013 Installation and Configuration – Installing BizTalk Adapter Pack (Part 12)

The Microsoft BizTalk Adapter for Oracle Database is a Windows Communication Foundation (WCF) custom binding. This binding contains a single custom transport binding element that enables communication with an Oracle database.

The following figure shows part of “BizTalk Oracle Adapter Architecture”:

BizTalk-Oracle-Adapter-Architecture

According to BizTalk official documentation, the support version of Oracle are:

  • Oracle database version 11.1,
  • Oracle database version 10.2,
  • Oracle database version 10.1,
  • Oracle database version 9.2

And supported client versions:

  • Oracle Data Access Components for Oracle Client 11.1.0.6 with Patch Set 11.1.0.7,
  • Oracle Data Access Components for Oracle Client 11.1.0.7

You can read more on how to install Oracle client here:

As I said earlier, I didn’t had any problem in development phase however in runtime I catch the following error:

The adapter failed to transmit message going to send port “SEND_Oracle” with URL “oracledb://connection”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.IO.FileNotFoundException: Could not load file or assembly ‘Oracle.DataAccess, Version=2.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342′ or one of its dependencies. The system cannot find the file specified.

File name: ‘Oracle.DataAccess, Version=2.112.1.2, Culture=neutral, PublicKeyToken=89b483f429c47342′ —> System.IO.FileNotFoundException: Could not load file or assembly ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342′ or one of its dependencies. The system cannot find the file specified.
File name: ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342′
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.

So I tried to check in the GAC if the correct assemblies were there and I realized that the client add installed a different version of the Oracle Client: Oracle 11g R2.

BizTalk-Oracle-Client-GAC-dll

CAUSE

When installing the Oracle WCF Adapter for BizTalk there is a design time requirement to use Oracle.DataAccess Version 2.111.7.0.

Official the Oracle 11g R2 is not supported and again according to official documentation I should use one of the supported clients. However my client only had access to this version and did not want to use another. Although not officially supported you can connect to Oracle 11g R2 database and use Oracle 11g R2 client with minor configuration adjustments.

SOLUTION

One possible solution to fix this problem is configuring Assembly Binding Redirection in the machine configuration file (Machine.config):

  • 32-bit: c:\Windows\Microsoft.NET\Framework\[version]\config\machine.config
  • 64-bit: c:\Windows\Microsoft.NET\Framework64\[version]\config\machine.config

Note: You should apply this in both 32 and 64-bit machine configuration files.

By using the <assemblyBinding> Element for <runtime> that will contain all the information about assembly version redirection and the locations of assemblies.

In this case you should apply the following configurations:

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
        <assemblyIdentity name="Oracle.DataAccess"
          publicKeyToken="89b483f429c47342" />
 
        <bindingRedirect oldVersion="2.111.7.0" newVersion="2.112.1.2" />
      </dependentAssembly>
       </assemblyBinding>
</runtime>

Just to be sure, I add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.


How to properly register a custom BizTalk Server Adapter

$
0
0

In this last week I’ve been migrating legacy custom adapters from previous BizTalk Versions (2004 and 2006) for recent version of BizTalk Server (2010 and 2013). In this particular case is an Isolated Adapter that in fact is a socket listener that will be listening on one or more TCP ports for a custom and private message format to address and solve an integration problem with legacy platforms of one of my clients. Working and creating custom adapter it’s always a funny task, it makes me remember and come back to my roots of .NET developer and how much I love this job.

Note: It’s also important to remember that recent version of BizTalk Server normally runs under 64-bit and because BizTalk Administration Console runs under 32-bits it’s imperative to register the adapter in both 32-bit and 64-bit versions of the BizTalk Adapter, at least if you want the adapter to run under 64-bit, nevertheless you always need to register under 32-bit.

If you are developing a custom adapter, you can register it with BizTalk Server by modifying and running one of the registry files included with the sample file adapter in the software development kit (SDK). Or, you can use the Adapter Registry Wizard to create a registry file. You can learn more about this topic here: Registering an Adapter.

Although it is a migration of an existing adapter which have worked correctly over several years I decide to optimize the adapter to run on new versions of NET Framework (4.0) and also to support 64-bit. The question and the main reason for this post is: How to properly register this custom BizTalk adapter?

How to properly register a custom BizTalk adapter

Again and this is very important:

  • On a 32-bit machine, the registry (.reg) file generated by the Adapter Registration wizard must be run from the command prompt.
  • On a 64-bit machine, the registry (.reg) file generated by the Adapter Registration wizard must be run both from the 32-bit and 64-bit command prompt.

So if you are in a 32-bit machine you only need to run the adapter registry (.reg) from the command prompt or even double-click in adapter registry (.reg) file.

However if you are in a64-bit machine you need extra steps:

  • If run the adapter registry (.reg) from the command prompt or even double-click in adapter registry (.reg) file – this will register the adapter under 64-bit.

If you try to check and add this new adapter in the BizTalk Administration Console (Adding the Adapter to BizTalk Server) you will notice that the adapter will not be present and referenced in the Adapter drop box.

  • So now you need to force to do the same in 32-bit, to accomplish that you need to open a 32-bit command prompt:
    • Click Start.
    • Type %windir%\SysWoW64\cmd.exe in Start Search box and press Enter
    • Run the same adapter registry (.reg) from this command prompt

Again, if you try to check and add this new adapter in the BizTalk Administration Console you will notice that the adapter now will be present in the drop box.



BizTalk Scheduled Task Adapter 4.0: Introduction and Installation process

$
0
0
Introduction

The BizTalk Scheduled Task Adapter is an in-process receive adapter that executes a prescribed task on a daily, weekly or monthly schedule. The adapter is configured entirely within BizTalk, all configurations is stored within the SSODB and can be exported and imported via binding files.

The schedule capabilities are similar to those available with the Windows Scheduled Task Service.

Four simple tasks are included in this version:

  • XmlStringStreamProvider – generates a BizTalk message from a configured Xml string
  • FileStreamProvider – generates a BizTalk message from the contents of a file
  • HttpDownload – generates a BizTalk message from data downloaded from a web site
  • SQLStreamProvider – generates a BizTalk message from the contents of a SQL Query (similar to the old SQL adapter)

Custom tasks can be created. Any .NET class that implements the appropriate interface can be scheduled.

Release History

This adapter is available since BizTalk Server 2004.

  • Release 1.02: last release in Apr 20 2008 by Greg Forsythe, this adapter works with BizTalk Server 2004, BizTalk Server 2006 and BizTalk Server 2006 R2. Compiled in .NET Framework 1.1
  • Release 2.0: last release in Apr 20 2008 by Greg Forsythe, this adapter works with BizTalk Server 2006 and BizTalk Server 2006 R2. Compiled in .NET Framework 2.0
  • Release 3.0: release in Aug 10 2010 by Greg Forsythe, this adapter was tested to work on BizTalk Server 2009. Compiled in .NET Framework 2.0
  • Release 4.0: release in June 12 2012 by Sandro Pereira, this adapter was tested to work on BizTalk Server 2010. Compiled in .NET Framework 4.0
Requirements

The Scheduled Task Adapter v4.0 will work with:

  • BizTalk Server 2010
  • .NET Framework 4.0

 

Installation Process

To install the adapter run "ScheduledTaskAdapter.msi".

  • In the “Welcome” screen press “Next”.

Scheduler-Task-Adapter-welcome-screen

  • In the “Select Installation Folder” screen you must set the installation locations were you what to install the adapter.

Scheduler-Task-Adapter-installation-folder-screen

  • The following screens are very straightforward – In the “Confirm Installation” screen press “Next”, then it will appear the installation progress and assuming all goes well a completion screen.

Scheduler-Task-Adapter-confirmation-screen

Scheduler-Task-Adapter-complete-screen

The setup will install the following assemblies in the selected folder (Default: C:\Program Files (x86)\Biztalk ScheduledTask Adapter):

  • Biztalk.Adapter.ScheduledTaskProperties.dll
  • Calendar.Schedules.dll
  • Microsoft.BizTalk.CommonSettings.dll
  • Microsoft.BizTalk.SqmFramework.dll
  • ScheduledTaskAdapter.Admin.dll
  • ScheduledTaskAdapter.dll
  • ScheduledTaskAdapter.TaskComponents.dll
  • stdole.dll

The setup will add the following assemblies to the Global Assembly Cache (GAC)

  • Biztalk.Adapter.ScheduledTaskProperties.dll
  • Calendar.Schedules.dll
  • ScheduledTaskAdapter.dll
  • ScheduledTaskAdapter.Admin.dll
  • ScheduledTaskAdapter.TaskComponents.dll

 

Post-Installation
Register the Adapter with BizTalk

As it happens with all adapters that we installed on our BizTalk Servers before we can begin to use it we need to register or configure the adapter. To accomplish that we need to:

  • Open BizTalk Administration Console
  • In the console left tree, expand “BizTalk Server Administration –> BizTalk Group –> Platform Settings” and then “Adapters”
  • Right-click on “Adapters” and add a new adapter by selecting the option “New –> Adapter”

register-Scheduler.Task-Adapter-New-Adapter

  • In the “Adapter Properties” window
    • Set the name of the adapter: Name = Schedule
    • In the adapter combo box select the option: Schedule
    • Set the description of the adapter: “BizTalk Scheduled Task Adapter. The schedule capabilities are similar to those available with the Windows Scheduled Task Service.” (this property is optional but I would suggest to always be filled)

register-Scheduler.Task-Adapter-New-Adapter-select-adapter-properties

Note: This configuration requires that you restart the host instance associated with the adapter.

register-Scheduler.Task-Adapter-New-Adapter-restart-host-instances

Using the adapter Context Properties

To utilize the Scheduled Task adapter’s context properties within a filter or orchestration the Biztalk.Adapter.ScheduledTaskProperties.dll must be deployed into the BizTalkMgmtDb.

This can be achieved using the Biztalk Deployment Wizard or equivalent tool.

Note: This step is optional; you only need to do this if you want to use Scheduled Task adapter’s context properties within a filter or orchestration.

As previously mentioned, you can deploy Biztalk.Adapter.ScheduledTaskProperties.dll in various ways; I suggest that you do the following steps:

  • Open BizTalk Administration Console
  • In the console left tree, expand “BizTalk Server Administration –> BizTalk Group” and then “Applications”
  • Right-click on “Applications” and add a new application by selecting the option “New –> Application”

New-application

  • In the “Adapter Properties” window
    • Set the name of the application: BizTalk.Global
    • Set the description of the application: “Application that contain common resources to several applications” (this property is optional but I would suggest to always be filled)

New-application-properties

  • Expand the application created previous and select the option “Resources”
  • Right-click and add a new BizTalk resource by selecting the option “New –> BizTalk Assemblies…”

New-resource

  • In the “Add Resources” window select “Add…” button and from the installation directory select the DLL “Biztalk.Adapter.ScheduledTaskProperties.dll”
    • And select the options: “Overwrite all”, “Add to the global assembly cache on add resource (gacutil)” and “Add to the global assembly cache on MSI file install (gacutil)”

New-resource-dll

  • Select “OK” button

Important note: The BizTalk assembly containing the orchestration code must also add this assembly as a reference

List of improvements in version 4.0

In this new version are available small improvements compared to the current version (3.0). We can highlight the following improvements or changes:

  • 24 hours support in “start time” property. Previous versions had an issue with setting the start time, as it shown 12 hours watch but no AM/PM.
  • Daily scheduler review. Solved a small bug on Daily Properties: unable to switch between “Every day” and “on these days”
  • Installation experience improved. You no longer need to manually add the DLL in GAC.
  • Support for 32 and 64 bit Host Instances.
  • Compiled in Visual Studio 2010 and .NET Framework 4.0.
  • Optimized for BizTalk Server 2010.
  • Documentation improved.

List of open source projects for BizTalk developers

$
0
0

For some time that I didn’t contribute to new articles on TechNet Wiki, only having systematically adding new errors in the article BizTalk: List of Errors and Warnings, Causes and Solutions

There are a number of open source projects: pipelines, adapters and functoids that can aid you as BizTalk developer. These resources are not the out of the box offered by BizTalk Server like WCF Publishing Wizard or BizTalk Server Adapter pack (that provides connectivity to SAP, Siebel, SQL and many more).

Through the internet you can find numerous open source projects created by people from community, Microsoft, Microsoft Community Contributors (MCC) and Microsoft® Most Valuable Professionals (MVP), which can help you speeding up the development process of our projects.

We can find in TechNet Wiki three articles describing a list of several projects:


New minor release of BizTalk Scheduled Task Adapter for BizTalk Server 2010 is now available

$
0
0

Finally I had some free time available to be able to update and fix some minor bugs which existed in the latest version of this adapter and already had been reported by community members.

I have to give a special thanks to maakku that reported a problem related to the Daily schedule properties… and the respective solution!!

So today a published a minor release of BizTalk Scheduled Task Adapter is available for download on CodePlex: BizTalk Scheduled Task Adapter v4.0

NOTE: the adapter is still in version 4.0, I have not modified the version. As I said earlier this is a minor release to solved small bugs.

codeplex-BizTalk-Scheduled-Task-Adapter-page

List of improvements in this minor release:

  • Daily scheduler review. Solved a small bug on Daily Properties: settings were not saved correctly when configuring daily schedule in admin console (see more here)
  • Support for 32 and 64 bit Host Instances.
  • Fix the version number of the adapter that was being recorded incorrectly as 3.0.0. After installing the adapter, in Programs and Features the version for the BizTalk Scheduled Task Adapter it was 3.0.0.

Note: The adapter was tested with success running in 32 and 64 bit Host Instances!


PowerShell to Configure BizTalk Server Host and Host Instances according to some of the Best Practices

$
0
0

Personally I like to create all my BizTalk Server installation and configuration process manually at least one time or maybe from time to time, but when we are dealing with several environments and even worse each environment with several BizTalk Servers… this can be very annoying and time consuming. In this case automation is the key!

One of the task that we need to do in all our new BizTalk environment over and over again is creating and configuring the Host, Host Instances and of course the adapter handlers.

What’s is Host, Host Instances and Adapter Handlers?

The BizTalk Host is a logical process and security boundary within BizTalk Server that represents a logical set of zero or more run-time processes in which you can deploy BizTalk Server services and artifacts (such as adapter handlers, receive locations, and orchestrations). Each host has a security group assigned to it and may contain multiple host instances, each on an individual machine, that perform the work of the host.

In turn, a host instance is the physical instance of a host on a computer running BizTalk Server. Each host instance belongs to exactly one host, and the service account of the host instance belongs to the security group of the host. The security group may be used to grant permissions to physical resources such as databases for use by any host instances in the host.

An adapter handler is an instance of a BizTalk host in which the adapter code runs. When you specify a send or receive handler for an adapter you are specifying which host instance the adapter code will run in the context of. An adapter handler is responsible for executing the adapter and contains properties for a specific instance of an adapter. A default BizTalk Server configuration will create adapter handlers for all of the installed adapters, but you may want to create additional adapter handlers for purposes of load balancing or to provide process isolation for a particular adapter handler.

Best practices to Configuring Hosts and Host Instances

As the official documentation specify, in addition to the high availability aspects of the host instance configuration, you should separate sending, receiving, processing, and tracking functionality into multiple hosts. This provides flexibility when configuring the workload in your BizTalk group and is the primary means of distributing processing across a BizTalk group.

This also allows you to stop one host without affecting other hosts. For example, you may want to stop sending messages to let them queue up in the MessageBox database, while still allowing the inbound receiving of messages to occur.

Separating host instances by functionality also provides some of the following benefits:

  • Each host instance has its own set of resources such as memory, handles, and threads in the .NET thread pool.
  • Multiple BizTalk Hosts will also reduce contention on the MessageBox database host queue tables since each host is assigned its own work queue tables in the MessageBox database.
  • Throttling is implemented in BizTalk Server at the host level. This allows you to set different throttling characteristics for each host.
  • Security is implemented at the host level; each host runs under a discrete Windows identity.

However this also may bring some potential drawbacks if too many host instances are created because each host instance is a Windows service (BTSNTSvc.exe or BTSNTSvc64.exe), which generates additional load against the MessageBox database and consumes computer resources (such as CPU, memory, threads), so you need to be careful.

Normally we read that we need to create at least 4 host instances: sending, receiving, processing, and tracking, but that’s not absolutely true because, at least with the newer environments, we typically use 64-bits versions and in this case we also need to create at least one Host Instance that will run on 32-bits because FTP adapter, SQL adapter, POP3 adapter and MIME Decoder on 64-bit host instances is not supported by the product (http://technet.microsoft.com/en-us/library/aa560166.aspx)

We can define that one of the best practices for hosts and host instances is the following:

  • BizTalkServerTrackingHost: A BizTalk Host that hosts tracking is responsible for moving the DTA and BAM tracking data from the MessageBox database to the BizTalk Tracking (DTA) and BAM Primary Import databases. This movement of tracking data has an impact on the performance of other BizTalk artifacts that are running in the same host that is hosting tracking. Thus, you should use a dedicated host that does nothing but host tracking.
    • Only the optionAllow Host Tracking” must be selected because we only will use this host for tracking.
  • BizTalkServerReceiveHost: All options (Allow Host Tracking”, “32-bits only” or “Make this default host in the group”) should be unselected. This host will be responsible for processing messages after they are picked up in a receive location. When a host contains a receiving item, such as a receive location (with a pipeline), the message decoding and decrypting occurs in a pipeline within this host.
    • All receive handlers, except the isolated ones like SOAP, HTTP, WCF-BasicHttp, WCF-WsHttp or WCF-CustomIsolated and 32 bit adapters (FTP,SQL and POP3) will be configured for this host. This will mean also that all receive locations will run in this host instance.
  • BizTalkServerReceive32Host: has the same goal as the previous however this must have the “32-bits only” option select so that we can run the 23-bits adapters.
    • The receive handlers for the FTP, SQL and POP3 adapters will be configured for this host.
  • BizTalkServerSendHost: All options (Allow Host Tracking”, “32-bits only” or “Make this default host in the group”) should be unselected. This host will be responsible for processing messages before they are sent out to the send port. When a host contains a sending item, such as a send port, the message signing and encryption occurs in a pipeline within this host.
    • All send handlers, except 32 bit adapters like native SQL and FTP adapter, will be configured for this host. This will mean also that all send ports will run in this host instance.
  • BizTalkServerSend32Host: has the same goal as the previous however this must have the “32-bits only” option select so that we can run the 32-bits adapters.
    • The Send handlers for the FTP and SQL adapters will be configured for this host.
  • BizTalkServerApplication: Only the option32-bits only” should be select in this host. This host will be responsible for process messages based on the instructions in orchestrations that need to run in 32-bits.
  • BizTalkServerApplication64Host: Only the optionMake this default host in the group” should be select in this host. This host will be responsible for process messages based on the instructions in all or most common orchestrations.

Note: You can create other Application Host if you want to separate process base in some application logic.

How can I automate this task?

Windows PowerShell is a Windows command-line shell designed especially for system administrators and can be used by BizTalk administrators to help them in automating tasks.

This is a simple script to configure the Host, Host Instance and Adapter Handlers described earlier in this post:
Function that will create a new BizTalk Host

function CreateBizTalkHost([string]$hostName, [int]$hostType, [string]$ntGroupName, [bool]$authTrusted, [bool]$isTrackingHost, [bool]$is32BitOnly)
{
    try
    {
        [System.Management.ManagementObject]$objHostSetting = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostSetting").CreateInstance()

        $objHostSetting["Name"] = $hostName
        $objHostSetting["HostType"] = $hostType
        $objHostSetting["NTGroupName"] = $ntGroupName
        $objHostSetting["AuthTrusted"] = $authTrusted
        $objHostSetting["IsHost32BitOnly"] = $is32BitOnly
        $objHostSetting["HostTracking"] = $isTrackingHost

        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::CreateOnly;

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objHostSettingType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objHostSettingType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objHostSetting, $putOptions)

		Write-Host "Host $hostName was successfully created" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("Another BizTalk Host with the same name already exists in the BizTalk group.") -eq $true)
        {
			Write-Host "$hostName can't be created because another BizTalk Host with the same name already exists in the BizTalk group." -Fore DarkRed
        }
		else{
        	write-Error "$hostName host could not be created: $_.Exception.ToString()"
		}
    }
}

Function that will update an existent BizTalk Host

function UpdateBizTalkHost([string]$hostName, [int]$hostType, [string]$ntGroupName, [bool]$authTrusted, [bool]$isTrackingHost, [bool]$is32BitOnly, [bool]$isDefaultHost)
{
    try
    {
        [System.Management.ManagementObject]$objHostSetting = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostSetting").CreateInstance()

        $objHostSetting["Name"] = $hostName
        $objHostSetting["HostType"] = $hostType
        $objHostSetting["NTGroupName"] = $ntGroupName
        $objHostSetting["AuthTrusted"] = $authTrusted
        $objHostSetting["IsHost32BitOnly"] = $is32BitOnly
        $objHostSetting["HostTracking"] = $isTrackingHost
		$objHostSetting["IsDefault"] = $isDefaultHost

        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::UpdateOnly; # This tells WMI it's an update.

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objHostSettingType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objHostSettingType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objHostSetting, $putOptions)

		Write-Host "Host $hostName was successfully updated" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
        write-Error "$hostName host could not be updated: $_.Exception.ToString()"
    }
}

Function that will create a new BizTalk Host Instance

function CreateBizTalkHostInstance([string]$hostName, [string]$serverName, [string]$username, [string]$password)
{
    try
    {
        [System.Management.ManagementObject]$objServerHost = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_ServerHost").CreateInstance()

        $objServerHost["HostName"] = $hostName
        $objServerHost["ServerName"] = $serverName
        $objServerHost.Map()

        [System.Management.ManagementObject]$objHostInstance = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostInstance").CreateInstance()

        $name = "Microsoft BizTalk Server " + $hostName + " " + $serverName
        $objHostInstance["Name"] = $name
        $objHostInstance.Install($username, $password, $true)

		Write-Host "HostInstance $hostName was mapped and installed successfully. Mapping created between Host: $hostName and Server: $Server);" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("Another object with the same key properties already exists.") -eq $true)
        {
			Write-Host "$hostName host instance can't be created because another object with the same key properties already exists." -Fore DarkRed
        }
		else{
        	write-Error "$hostName host instance on server $Server could not be created: $_.Exception.ToString()"
		}
    }
}

Function that will delete an existent host handlers in the adapters

function DeleteBizTalkAdapterHandler([string]$adapterName, [string]$direction, [string]$hostName)
{
	try
    {
		if($direction -eq 'Receive')
		{
			[System.Management.ManagementObject]$objHandler = get-wmiobject 'MSBTS_ReceiveHandler' -namespace 'root\MicrosoftBizTalkServer' -filter "HostName='$hostName' AND AdapterName='$adapterName'"
	        $objHandler.Delete()
		}
		else
		{
			[System.Management.ManagementObject]$objHandler = get-wmiobject 'MSBTS_SendHandler2' -namespace 'root\MicrosoftBizTalkServer' -filter "HostName='$hostName' AND AdapterName='$adapterName'"
	        $objHandler.Delete()
		}

		Write-Host "$direction handler for $adapterName / $hostName was successfully deleted" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
        if ($_.Exception.Message -eq "You cannot call a method on a null-valued expression.")
        {
			Write-Host "$adapterName $direction Handler for $hostName does not exist" -Fore DarkRed
        }
        elseif ($_.Exception.Message.IndexOf("Cannot delete a receive handler that is used by") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use and can't be deleted." -Fore DarkRed
        }
		elseif ($_.Exception.Message.IndexOf("Cannot delete a send handler that is used by") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use and can't be deleted." -Fore DarkRed
        }
		elseif ($_.Exception.Message.IndexOf("Cannot delete this object since at least one receive location is associated with it") -ne -1)
        {
			Write-Host "$adapterName $direction Handler for $hostName is in use by at least one receive location and can't be deleted." -Fore DarkRed
        }
        else
        {
            write-Error "$adapterName $direction Handler for $hostName could not be deleted: $_.Exception.ToString()"
        }
    }
}

Function that will create a handler for a specific adapter on the host

function CreateBizTalkAdapterHandler([string]$adapterName, [string]$direction, [string]$hostName, [string]$originalDefaulHostName, [boolean]$isDefaultHandler, [boolean]$removeOriginalHostInstance)
{
	if($direction -eq 'Receive')
	{
		[System.Management.ManagementObject]$objAdapterHandler = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_ReceiveHandler").CreateInstance()
		$objAdapterHandler["AdapterName"] = $adapterName
	    $objAdapterHandler["HostName"] = $hostName
	}
	else
	{
		[System.Management.ManagementObject]$objAdapterHandler = ([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_SendHandler2").CreateInstance()
		$objAdapterHandler["AdapterName"] = $adapterName
	    $objAdapterHandler["HostName"] = $hostName
	    $objAdapterHandler["IsDefault"] = $isDefaultHandler
	}

    try
    {
        $putOptions = new-Object System.Management.PutOptions
        $putOptions.Type = [System.Management.PutType]::CreateOnly;

        [Type[]] $targetTypes = New-Object System.Type[] 1
        $targetTypes[0] = $putOptions.GetType()

        $sysMgmtAssemblyName = "System.Management"
        $sysMgmtAssembly = [System.Reflection.Assembly]::LoadWithPartialName($sysMgmtAssemblyName)
        $objAdapterHandlerType = $sysMgmtAssembly.GetType("System.Management.ManagementObject")

        [Reflection.MethodInfo] $methodInfo = $objAdapterHandlerType.GetMethod("Put", $targetTypes)
        $methodInfo.Invoke($objAdapterHandler, $putOptions)

        Write-Host "$adapterName $direction Handler for $hostName was successfully created" -Fore DarkGreen
    }
    catch [System.Management.Automation.RuntimeException]
    {
		if ($_.Exception.Message.Contains("The specified BizTalk Host is already a receive handler for this adapter.") -eq $true)
        {
			Write-Host "$hostName is already a $direction Handler for $adapterName adapter." -Fore DarkRed
        }
		elseif($_.Exception.Message.Contains("The specified BizTalk Host is already a send handler for this adapter.") -eq $true)
        {
			Write-Host "$hostName is already a $direction Handler for $adapterName adapter." -Fore DarkRed
        }
		else {
        	write-Error "$adapterName $direction Handler for $hostName could not be created: $_.Exception.ToString()"
		}
    }

	if($removeOriginalHostInstance)
	{
		DeleteBizTalkAdapterHandler $adapterName $direction $originalDefaulHostName
	}
}

Function that will have the logic you want to implement to create the default hosts and host instances and add configure the host instances to the various handlers

function ConfiguringBizTalkServerHostAndHostInstances
{
	# Separate sending, receiving, processing, and tracking functionality into multiple hosts.
	# This provides flexibility when configuring the workload and enables you to stop one host without affecting other hosts.
	# you can use a common well use convention to define the name of the host:
	#  - <Job>_<bit support>_<seq>_<adapter/functionality>_<throughput>_<priority>_<clustered>
	# Sample 'Rcv_x32_1_FTP_L_Critical_Clustered'
	# But I will use a more simple convencion
	# Defining the names of the hosts
	[string]$receiveHostName = 'BizTalkServerReceiveHost'
	[string]$sendHostName = 'BizTalkServerSendHost'
	[string]$processingHostName = 'BizTalkServerApplication64Host' # use this to create another processing host
	[string]$trackingHostName = 'BizTalkServerTrackingHost'
	# Note: why we need to create 32bits hosts? FTP, POP3 and SQL doesn't support 64bits
	[string]$receive32HostName = 'BizTalkServerReceive32Host'
	[string]$send32HostName = 'BizTalkServerSend32Host'

	# 'BizTalkServerApplication' is the default host instance created when you install the biztalk on your box.
	# This application will be running on "32-bit only".
	[string]$defaultHostName = 'BizTalkServerApplication'

 	##############################
	# Creating hosts for receiving
	# HostType: Invalid: 0, In-process:	1, Isolated: 2
	CreateBizTalkHost $receiveHostName 1 $ntHostGroupName $false $false $false
	CreateBizTalkHost $receive32HostName 1 $ntHostGroupName $false $false $true

	# Create a host instances for receiving associated with the previous hosts created
	CreateBizTalkHostInstance $receiveHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword
	CreateBizTalkHostInstance $receive32HostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Set adapters that should be handled by receiving host instance
	CreateBizTalkAdapterHandler 'FILE' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MQSeries' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MSMQ' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-Custom' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetMsmq' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetNamedPipe' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetTcp' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'Windows SharePoint Services' 'Receive' $receiveHostName $defaultHostName $false $removeOriginalAdapterHandler
	#32 bits adapters
	CreateBizTalkAdapterHandler 'FTP' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'POP3' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SQL' 'Receive' $receive32HostName $defaultHostName $false $removeOriginalAdapterHandler

 	##############################
	# Creating hosts for sending
	# HostType: Invalid: 0, In-process:	1, Isolated: 2
	CreateBizTalkHost $sendHostName 1 $ntHostGroupName $false $false $false
	CreateBizTalkHost $send32HostName 1 $ntHostGroupName $false $false $true

	# Create a host instances for sending associated with the previous hosts created
	CreateBizTalkHostInstance $sendHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword
	CreateBizTalkHostInstance $send32HostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Set adapters that should be handled by sending host instance
	CreateBizTalkAdapterHandler 'FILE' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'HTTP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MQSeries' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'MSMQ' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SOAP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SMTP' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-BasicHttp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-Custom' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetMsmq' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetNamedPipe' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-NetTcp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'WCF-WSHttp' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'Windows SharePoint Services' 'Send' $sendHostName $defaultHostName $true $removeOriginalAdapterHandler
	#32 bits adapters
	CreateBizTalkAdapterHandler 'FTP' 'Send' $send32HostName $defaultHostName $true $removeOriginalAdapterHandler
	CreateBizTalkAdapterHandler 'SQL' 'Send' $send32HostName $defaultHostName $true $removeOriginalAdapterHandler

	# Create a host for tracking
	CreateBizTalkHost $trackingHostName 1 $ntHostGroupName $false $true $false

	# Create a host for orchestrations
	CreateBizTalkHost $processingHostName 1 $ntHostGroupName $false $false $false

	# Create a host instance for orchestrations
	CreateBizTalkHostInstance $processingHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Create a host instance for tracking
	CreateBizTalkHostInstance $trackingHostName $bizTalkServerName $hostCredentials.UserName $hostCredentialsPassword

	# Remove "Allow Host Tracking" options from BizTalkServerApplication Host
	UpdateBizTalkHost $defaultHostName 1 $ntHostGroupName $false $false $true $true

	# Updating the processinh host to be the default host
	UpdateBizTalkHost $processingHostName 1 $ntHostGroupName $false $false $false $true
}

And in the last the main script

Write-Host "Starting configure the BizTalk Server environment..." -Fore DarkGreen

# General variables
# Defining the BizTalk Server Name, this line will read the Server name on which the script is running
$bizTalkServerName = $(Get-WmiObject Win32_Computersystem).name

# STEP 1
# The Windows group is used to control access of a specif host and associated host instances to databases and other
# resources. Each instance of this host must run under a user account that is a member of this group.
# Note that you can change the Windows group only if no instances of this host exist.
# Defining the name of the group the BizTalk hosts should run under
[string]$ntHostGroupName = Read-Host -Prompt "Please enter windows group to control access to Hosts and ssociated Host Instances"

# STEP 2
# This account must have SQL Server permissions. The recommended way to grant these permissions is to add this account
# to the BizTalk Server Host Windows group.
# BizTalk Server will add this account to the "Log on as a service" security policy.
# For domain accounts, use "domain\user" format
# Defining the credentials in witch the host instance should run under.
try
{
	$domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
	$domainName = $domain.name
}
catch
{
	$domainName = $(Get-WmiObject Win32_Computersystem).name
}
$hostCredentials = $Host.ui.PromptForCredential("Logon Credentials","This account must have SQL Server permissions. The recommended way to grant these permissions is to add this account to the BizTalk Server Host Windows group.

BizTalk Server will add this account to the 'Log on as a service' security policy", $domainName + "\", "");
[String]$hostCredentialsPassword = [Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR($hostCredentials.Password));

# STEP 3
# Defining the option if you want to automatically try to remove the BizTalkServerApplication Host Instance from
# the Adapters handlers
$windowsShell = new-object -comobject wscript.shell
$questionResult = $windowsShell.popup("Do you want to try to remove the BizTalkServerApplication Host Instance from the Adapters handlers?

Note: The script cannot remove the default host instances if there are any receiveports, sendports or orchestrations configured.",
						  0,"BizTalk Applications, Receive and Send Ports",4)

If ($questionResult -eq 6) {
	$removeOriginalAdapterHandler = $true
}
else {
	$removeOriginalAdapterHandler = $false
}

# STEP 4
# Create default hosts, host instances and handlers
Write-Host "Creating hosts and host instances..." -Fore DarkGreen
ConfiguringBizTalkServerHostAndHostInstances

# STEP 5
# This configurations changes requires host instances restart for the changes to take effect.
# Check if you want to restart the Host Instances
Write-Host "Host and Host Instance configuration is almost completed..." -Fore DarkGreen
$questionResult = $windowsShell.popup("This configurations changes requires host instances restart for the changes to take effect.

Do you want to restart the Host Instances now?", 0,"Please restart Host Instances",4)
If ($questionResult -eq 6) {
	get-service BTS* | foreach-object -process {restart-service $_.Name}
	Write-Host "Restart Host Instance completed..." -Fore DarkGreen
}

# STEP 6
# Check if you want to properly configure BizTalk Services and Enterprise Single Sign-On Service 'Startup type' property
# to Automatic (Delayed Start)
$questionResult = $windowsShell.popup("By default, the 'Startup type' propriety of BizTalk Services and Enterprise Single Sign-On Service are set as 'Automatic', however BizTalk Server services may not start automatically after a system restart, to avoid this behavior you must config the 'Startup type' to 'Automatic (Delayed Start)'.

Do you want to configure BizTalk Services to 'Automatic (Delayed Start)'?", 0,"Configure BizTalk Services to Automatic (Delayed Start)",4)
If ($questionResult -eq 6) {
	#=== Name of the Enterprise Single Sign-On Service. ===#
	$entSSOServiceName = 'ENTSSO'

	#=== Change the startup type for BizTalk services to Automatic (Delayed Start) ===#
	get-service BTSSvc* | foreach-object -process { SC.EXE config $_.Name start= delayed-auto}

	#=== Change the startup type for Enterprise Single Sign-On Service to Automatic (Delayed Start) ===#
	SC.EXE config $entSSOServiceName start= delayed-auto

	Write-Host "BizTalk Services and SSO configured successfully..." -Fore DarkGreen
}

Write-Host "Your BizTalk Server environment is now properly configured" -Fore DarkGreen

The script can be found and download on Microsoft TechNet Gallery:
PowerShell to Configure BizTalk Server Host and Host Instances (7.4 KB)
Microsoft TechNet Gallery


BizTalk Adapter 2.0 for mySAP Business Suite: Error in Check Transaction Failed to load the runtime

$
0
0

This weekend after installing .NET Framework 4.0 in a BizTalk Server 2006 R2 environment, the BizTalk Adapter 2.0 for mySAP Business Suite started to throw the following error when he tried to receive data from the SAP system.

“Event Source: BizTalk Adapter v2.0 for mySAP Business Suite
Description: Error in Check Transaction: Failed to load the runtime.
(Exception from HRESULT: 0x80131700)”

BizTalk-Adapter-mySAP-Business-Suite-Transaction-Failed-to-load-the-runtime

CAUSE

This issue occurs after installing .NET Framework 4.0. The registration of the assembly used by mySAP Business Suite does not specify the correct version of the .NET Framework. When .NET Framework 4.0 is installed, the assembly will try to use the newer framework and then raise this error.

SOLUTION

You need to manually reregister the sapreceiver.dll (this DLL is usually in this folder: “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\”). To accomplish that you need to:

  • Execute cmd (Start → cmd)
  • Type “cd C:\Windows\Microsoft.NET\Framework\v1.1.4322”
  • And execute the following command to fixed the problem:
    • regasm.exe “C:\Program Files\Microsoft BizTalk Adapter v2.0 for mySAP Business Suite\sapreceiver.dll”

Note: When you install .NET Framework 4.0 in older versions of BizTalk Server like BizTalk Server 2006 or 2006 R2, normally, you will also have problems with the Enterprise Single Sign-On Service for the exact same reasons and the solution is also to manually reregister the DLL but this time the SSOSQL.dll. To find more about this error check: Fixing BizTalk ENTSSO – Could not create SSOSQL. To fix the problem, reinstall SSO or try ‘regasm SSOSQL.dll’ from a Visual Studio command prompt.

References:


Viewing all 47 articles
Browse latest View live