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

BizTalk DevOps: How to configure Default Dynamic Send Port Handlers with PowerShell

$
0
0

As happens almost every year on this day (my birthday), I always try to write a post for the BizTalk community… something like a gift/present to the community… today will be automate the task of configuring default Dynamic Send ports handlers using PowerShell.

Since BizTalk Server 2013 we have available a new feature: Configurable Dynamic Send Port Handler. Which means that, when we are creating a Dynamic Send Port, an adapter Send Handler can be configurable for every installed adapter, by default it uses the default send handler associated in each adapter. This Includes both One-Way and Solicit-Response Dynamic Ports.

Note that in previous BizTalk versions, a dynamic send port uses the adapter’s default host, and we cannot change this behavior.

However, this new features also brings us some setbacks, special for BizTalk Administrators, for example:

  • When we are installing a new environment, if we install the EDI features, this will add a dynamic port call “ResendPort” (don’t need to describe the propose of this port) and the default send handler for each adapter will be the “BizTalkServerApplication”;
    • If we create different or dedicated host and host instances for each functionality, for example a host instance for receive, send, process (orchestrations), tracking and so on; of course then we need to associate them as a specific handler of each adapter (receive or send handler) and if we want to delete the “BizTalkServerApplication” as a send handler for each adapter… we can’t, we first need to:
      • Manually reconfigure the default Dynamic Send port handlers for each dynamic port first, configuring them with the new default send handler;
      • and then manually delete the “BizTalkServerApplication” as a send handler for each adapter;
  • The same happens when we install a new adapter. By default, it assumes the default host in the group as the default send handler of the adapter and in consequence the default send handler associated with this adapter in the existing dynamic send ports. Which means that once again we need to manually reconfigure the send handler in all the existing dynamic send ports for this new adapter;
  • And so on;

All of these tasks are time consuming, and to be fair, they are a little boring to do after we know how to do it manually;

So how can we automate tasks? and reuse them whenever necessary and at the same time saving significant time for other tasks?

Using PowerShell is a good option. 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 repetitive tasks or tasks that are time consuming to perform manually.

This is a simple script that allows you to configure the default send handlers associated with all the existing Dynamic Send ports in your environment:

[string] $sendHost32bits = "BizTalkServerSend32Host"
[string] $sendHost64bits = "BizTalkServerSendHost"

$catalog = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer
$catalog.ConnectionString = "SERVER=$bizTalkDbServer;DATABASE=$bizTalkDbName;Integrated Security=SSPI"

foreach($sendPort in $catalog.SendPorts)
{
    if($sendPort.IsDynamic -eq' True')
    {
        # A Dynamic send port was found so now we need to configure the send handler as desired
        # 64 bits adapters
        # Changing the default send handlers of the dynamic port
        $sendPort.SetSendHandler("FILE", $sendHost64bits)
        $sendPort.SetSendHandler("HTTP", $sendHost64bits)
        $sendPort.SetSendHandler("MQSeries", $sendHost64bits)
        $sendPort.SetSendHandler("MSMQ", $sendHost64bits)
        $sendPort.SetSendHandler("SB-Messaging", $sendHost64bits)
        $sendPort.SetSendHandler("SFTP", $sendHost64bits)
        $sendPort.SetSendHandler("SOAP", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-BasicHttp", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-BasicHttpRelay", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-Custom", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-NetMsmq", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-NetNamedPipe", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-NetTcp", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-NetTcpRelay", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-SQL", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-WebHttp", $sendHost64bits)
        $sendPort.SetSendHandler("WCF-WSHttp", $sendHost64bits)
        $sendPort.SetSendHandler("Windows SharePoint Services", $sendHost64bits)       

        # 32 bits adapters
        # SMTP Supports 64 bits but I want to run in 32 because of the MIME/SMIME Encoder
        $sendPort.SetSendHandler("FTP", $sendHost32bits)
        $sendPort.SetSendHandler("SMTP", $sendHost32bits)
        $sendPort.SetSendHandler("SQL", $sendHost32bits)
    }
}

$catalog.SaveChanges()

Prerequisites for this script: The host, host instances and send handlers needs to be already configured in your environment before you run the script;

THIS POWERSHELL IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

The full script can be found and download on Microsoft TechNet Gallery:
PowerShell to configure Default Dynamic Send Port Handlers for each Adapter (3.0 KB)
Microsoft TechNet Gallery


BizTalk DevOps: How to configure Receive Handlers from existing Receive locations with PowerShell

$
0
0

Following the topic from my previous post, when we are configuring/optimizing a new environment, if some features are installed like EDI features or RosettaNet Accelerator, if we create different or dedicated host and host instances for each functionality, for example a host instance for receive, send, process (orchestrations), tracking and so on; of course then we need to associate them as a specific handler of each adapter (receive or send handler) and if we want to delete the “BizTalkServerApplication” as a receive handler from each adapter… we can’t!

This happens because, at least, both EDI and RosettaNet will create during the installation some Receive Ports:

  • BatchControlMessageRecvPort with a receive location BatchControlMessageRecvLoc using SQL Adapter
  • ResendReceivePort with a receive location ResendReceiveLocation using SQL Adapter
  • LOB_To_PrivateInitiator with a receive location LOB_To_PrivateInitiator using SQL Adapter
  • LOB_To_PrivateResponder with a receive location LOB_To_PrivateResponder using SQL Adapter

And all these ports, by default during the installation, are configured with the only existing Receive handler available at the time: “BizTalkServerApplication”.

To accomplish the task of deleting “BizTalkServerApplication” as a receive handler of each adapter, we need to do basically the same steps described in my last post:

  • Manually reconfigure the Receive handler for each the existing receive location first, configuring them with the new Receive Handler;
  • and then manually delete the “BizTalkServerApplication” as a Receive handler for each adapter;

This task can be more normal to happen on the first time we configure/optimize the environment – day one of the BizTalk Server – but can be more critical if you reach to an existing environment, already containing several BizTalk Applications running, that is not configured according to best practices in terms of host and host instances.

Once again, all of these tasks are time consuming, and to be fair… again…, they are a little boring to do after we know how to do it manually;

So how can we automate tasks? and reuse them whenever necessary and at the same time saving significant time for other tasks?

Using PowerShell is a good option J. 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 repetitive tasks or tasks that are time consuming to perform manually.

This is a simple script that allows you to configure the receive handlers associated with all the existing Receive Ports in your environment that are using the SQL Adapter, but this can be easily changed to cover all the Receive Locations independently of the configured adapter:

$catalog = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer
$catalog.ConnectionString = "SERVER=$bizTalkDbServer;DATABASE=$bizTalkDbName;Integrated Security=SSPI"

foreach($receivePort in $catalog.ReceivePorts)
{
    # For each receive location in your environment
    foreach($recLocation in $receivePort.ReceiveLocations)
    {
        # In this case I want only Receive location that are using SQL Adapter
        if($recLocation.ReceiveHandler.TransportType.Name -eq 'SQL')
        {
            # Let's look for receive handlers associated with SQL Adapter
            foreach ($handler in $catalog.ReceiveHandlers)
            {
                # if is a SQL Adapter Receive Handler
                if ($handler.TransportType.Name -eq "SQL")
                {
                    # And is not BizTalkServerApplication, then configure that as the handler of the receive location
                    # Note: that in this case we will configure as a Receive Handler of the Receive location, the first 
                    #       receive handler that we find that is not the "BizTalkServerApplication"
                    #       because the goal is to delete this handler
                    if($handler.Name -ne 'BizTalkServerApplication')
                    { 
                        $recLocation.ReceiveHandler = $handler
                        break
                    }
                }
            }
        }
    }
}
$catalog.SaveChanges()

Prerequisites for this script: The host, host instances and Receive handlers needs to be already configured in your environment before you run the script;

THIS POWERSHELL IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

The full script can be found and download on Microsoft TechNet Gallery:
PowerShell to Configure Receive Handlers from existing Receive locations (3.0 KB)
Microsoft TechNet Gallery

BizTalk DevOps: Configure the Default Send Handler as the Send Handler for each existing static Send Ports with PowerShell

$
0
0

In the sequence of my last two post (here and here) and following the same topic, in order to finalize it, let’s talk about the last option and see how we can accomplish the same goal but this type configuring the Send Handler for existing static Send Ports in your environment.

Well, the two previous post are, in my opinion, more critical than this one for se simple reason that the default BizTalk installation will had ports in your environment that needs to be configure if you want to configure BizTalk Host in a High Availability way, i.e., dedicate logical hosts to run specific areas of functionality such as receiving messages, sending messages, processing orchestrations or tracking data.

However, and although less critical, static send ports can also be a problem in some scenarios, for example:

  • If you install ESB Toolkit before configuring your hosts for each functionality, because during the ESB Toolkit installation it will also be created a static send port call “ALL.Exceptions” that connects with SQL “EsbExceptionDb” database. And this port will be configured with the default send handler (at that time) configured in your environment, that is by default the “BizTalkServerApplication”
  • but also if you reach to an existing environment, already containing several BizTalk Applications running, that is not configured according to best practices in terms of host and host instances (dedicate logical hosts for each functionality).

Once again, we need to do basically do the same steps described in my last two posts to accomplish the task of deleting “BizTalkServerApplication”, this time as a send handler of each adapter:

  • Manually reconfigure the Send handler for each the existing Static Send Port first, configuring them with the new or correct Send Handler;
  • and then manually delete the “BizTalkServerApplication” as a Send handler for each adapter;

You may have heard this before, but it never hurts, all of these tasks are time consuming, and a little boring to do after a while or if we need to do it several times;

So how can we automate tasks? and reuse them whenever necessary and at the same time saving significant time for other tasks?

Using PowerShell is a good option J. 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 repetitive tasks or tasks that are time consuming to perform manually.

This is a simple script that allows you to configure the Send handler associated with all the existing Static Send Ports in your environment independently of the adapter that is configured:

$catalog = New-Object Microsoft.BizTalk.ExplorerOM.BtsCatalogExplorer
$catalog.ConnectionString = "SERVER=$bizTalkDbServer;DATABASE=$bizTalkDbName;Integrated Security=SSPI"

foreach($SendPort in $catalog.SendPorts)
{
    # For each receive location in your environment
    if($sendPort.IsDynamic -eq $False)
    {
        # Let's look for send handlers associated with Adapter configured in the send port
        foreach ($handler in $catalog.SendHandlers)
        {
            # if the Send Handler is associated with the Adapter configured in the send port
            if ($handler.TransportType.Name -eq $sendPort.PrimaryTransport.TransportType.Name)
            {
                # We will configured the port with the default send handler associated in each adapter in you system  
                # independently if it is "BizTalkServerApplication" or not.
                # Note: it's is recomended that you first configure the default send handlers for each adapter 
                #       and also not to use the "BizTalkServerApplication" (my personal recomendation)
                if($handler.IsDefault)
                { 
                    $sendPort.PrimaryTransport.SendHandler = $handler
                    break
                }
            }
        }
    }
}
$catalog.SaveChanges()

Prerequisites for this script: The host, host instances and Receive handlers needs to be already configured in your environment before you run the script;

THIS POWERSHELL IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.

The full script can be found and download on Microsoft TechNet Gallery:
PowerShell to Configure the Default Send Handler for each static Send Port (3.0 KB)
Microsoft TechNet Gallery

BizTalk Server WCF adapter: Unable to connect to the remote server. System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:8888

$
0
0

First of all, Happy birthday BizTalk Server for your 16th birthday! For does you don’ remember, the first version of BizTalk Server was release 12/12/2000, Congratulations!!

Continuing with the topic of my last posts “Errors and Warnings, Causes and Solutions”, we will talk about an error that I face today using the BizTalk Server WCF adapter while trying to communicate with an external WCF service:

System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://<ip/host name>/<ServiceName>.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. —> System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:8888
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)

— End of inner exception stack trace —

at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStreamAsyncResult.CompleteGetRequestStrea

BizTalk-WCF-Adapter-Unable-to-connect-to-the-remote-server

If this problem happens, it normally means that the IP address or host name specify in the URL exists but: it has no services listening on the specified port or there is a firewall stopping you.

However, I try to open the URL using the browser in the BizTalk machine and I was able to access without any problem, which means, it wasn’t a firewall problem and the service exist on that specific port.

Causes

Again, this type of problem normally means that the IP address or host name specify in the URL exists but:

  • It has no services listening on the specified port;
  • Or there is a firewall stopping you.

But… it also can be a proxy problem that may be blocking the access to the service! In fact, this was my problem.

Solution

I will not address the first two possible causes here, instead I will focus in what was my problem, proxies, and how can you solve it.

On the HTTP Transport bindings of the WCF adapter there are several properties to control the proxy, like:

  • proxyAddress: A URI that specifies the address of the HTTP proxy. If useSystemWebProxy is true, this setting must be null. The default is null.
  • proxyAuthenticationSchema: Specifies the protocol used for authenticating client requests being processed by an HTTP proxy. The default is Anonymous.
  • bypassProxyOnLocal: A Boolean value that indicates whether to bypass the proxy server for local addresses. The default is false.

and others properties. But also, contains a very important property: useDefaultWebProxy – this is a Boolean value that specifies whether the machine-wide proxy settings are used rather than the user specific settings. The default is true.

BizTalk-WCF-Adapter-useDefaultWebProxy-true

But how can you know there is a proxy set on the server?

You can check this using one of this two option:

  • You can open Command Prompt (CMD) and type the following command:

reg query “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings” | find /i “proxyserver”

BizTalk-WCF-Adapter-check-if-proxy-is-set

  • Or Open the Internet Explorer and click the Tools button.
    • Click on Internet Options and then click on the Connections tab.
    • Click “LAN settings”.

BizTalk-WCF-Adapter-check-if-proxy-is-set-in-internet-explorer

    • You can also click in “Advanced” to check more details

If you notice in the pictures there is a default proxy set in the server and there are some exceptions defined in the Internet Explorer, a few names and some IPs. One of this IP’s was in fact the IP of the machine that was hosting the service that I was trying to communicate.

In my case to solve the problem I just need to set the useDefaultWebProxy property in the HTTP transport bindings of my WCF port to false.

BizTalk-WCF-Adapter-useDefaultWebProxy-false

BizTalk Scheduled Task Adapter 6.0: 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 are 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 website
  • 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 6.0: release on March 1, 2017, by Sandro Pereira, this adapter was tested to work on BizTalk Server 2016. Compiled in .NET Framework 4.6
  • Release 5.0: release on February 18, 2015, by Sandro Pereira, this adapter was tested to work on BizTalk Server 2013 R2. Compiled in .NET Framework 4.5
  • Release 4.0: release on June 12, 2012, by Sandro Pereira, this adapter was tested to work on BizTalk Server 2010. Compiled in .NET Framework 4.0
  • Release 3.0: release on Aug 10, 2010, by Greg Forsythe, this adapter was tested to work on BizTalk Server 2009. Compiled in .NET Framework 2.0
  • Release 2.0: last release on 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 1.02: last release on 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

Requirements

The Scheduled Task Adapter v6.0 will work with:

  • BizTalk Server 2016
  • .NET Framework 4.6

How to install BizTalk Scheduled Task Adapter

To install the adapter you need to run “ScheduledTaskAdapter.msi”.

  • In the “Welcome” screen, click “Next”.

01-BizTalk-Scheduled-Task-Adapter-6.0-welcome

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

02-BizTalk-Scheduled-Task-Adapter-6.0-Select-Installation-Folder

  • In the “Confirm Installation” screen, click “Next”, then it will appear the installation progress

03-BizTalk-Scheduled-Task-Adapter-6.0-Confirm-Installation

  • Assuming all goes well, the “Installation Complete” screen will appear. Click “Close” to finish the installation process.

04-BizTalk-Scheduled-Task-Adapter-6.0-Installation-Complete

The setup will install the following assemblies in the selected folder (The default folder is: C:\Program Files (x86)\BizTalk ScheduledTask Adapter 6.0):

  • BizTalk Scheduled Task Adapter.pdf (Installation manual)
  • 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

The setup will add the following registry key:

  • HKEY_CLASSES_ROOT\CLSID\{7A4BDD2A-3063-4f57-A108-DEA05DEB417E}

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”

05-BizTalk-Scheduled-Task-Adapter-6.0-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)

06-BizTalk-Scheduled-Task-Adapter-6.0-New-Adapter-Schedule

  • Note: This configuration requires that you restart the host instance associated with the adapter. At this moment, click “Ok” to continue the configuration process.

07-BizTalk-Scheduled-Task-Adapter-6.0-New-Adapter-restart-hosts

  • [Optional] By default, the Receive Handler configured for the BizTalk Scheduled Task Adapter will be the default Host configured in the environment, that normally is “BizTalkServerApplication”. We can change this behavior by:
    • In the BizTalk Server Administration Console, expand “BizTalk Server Administration”, expand “BizTalk Group”, expand “Platform Settings”, and then expand “Adapters”.
    • In the expanded adapter list, right-click the Schedule adapter and then select the option “New –> Receive Handler

08-BizTalk-Scheduled-Task-Adapter-6.0-New-Receive-Handler

    • In the Schedule – Adapter Handle Properties” dialog box, on the General tab, in the Host Name list, select the host with which the adapter handler will be associated. And then click “Ok”

09-BizTalk-Scheduled-Task-Adapter-6.0-New-Receive-Handler-2

    • Again, at this point, a pop-up will appear notifying that this configuration requires that you restart the host instances associated with the adapter. At this moment, click “Ok” to finish the configuration process.

07-BizTalk-Scheduled-Task-Adapter-6.0-New-Adapter-restart-hosts

  • To finish this configuration process, in the BizTalk Server Administration console tree, expand BizTalk Server Administration, expand the BizTalk group, click Platform Settings, and then click Host Instances.
  • In the details pane, select host instance(s) you want to restart, right-click and then click “Restart”.

Using the adapter Context Properties (Optional)

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”

10-BizTalk-Scheduled-Task-Adapter-6.0-New-Application

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

11-BizTalk-Scheduled-Task-Adapter-6.0-New-Application

  • 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…”

12-BizTalk-Scheduled-Task-Adapter-6.0-New-Application-Add-Resource

  • In the “Add Resources” window select “Add…” button and from the installation directory select the DLL “Biztalk.Adapter.ScheduledTaskProperties.dll” (You can find this DLL on the adapter installation folder, by default, C:\Program Files (x86)\BizTalk ScheduledTask Adapter 6.0)
    • 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)”

13-BizTalk-Scheduled-Task-Adapter-6.0-New-Application-Add-Resource

  • Select “OK” button

WCF-SQL Adapter: Connecting to the LOB system has failed. A network-related or instance-specific error occurred while establishing a connection to SQL Server

$
0
0

I been delivering a lot of BizTalk Server Training Courses for Developers and for Administrator in the past years that I normally like to call them “Developing BizTalk Server version Course” or “BizTalk Server Operations, Administration, and Maintenance (OAM) course” – yes I know, I am very creative in terms of names – and one of the good things about using Azure Virtual Machines for that is that we can easily create several developer machines in a short period of time and manage them for not consuming resources. And normally on of the task that is present in both courses is to configure BizTalk Server environment, because I believe that all BizTalk Developers should know the basics of BizTalk Server in terms of installation, configuration and optimizations – tasks that are normally done by BizTalk Administrations – I can go further and say that, in my personal opinion, if you don’t know these basic concepts you are not truly a BizTalk Developer because many things can be done by configurations and not code.

One of these tasks is to install and configure BizTalk Server LOB adapters, in especially SQL Server adapter, since in a Developer standalone machine we will need to have SQL Server, so it is easy to test this LOB Adapter. However, if we create the Azure BizTalk Server 2016 Developer machine, configure BizTalk Server and then install and configure LOB adapters without doing anything more and you try to create a BizTalk Server solution using Visual Studio and generate SQL Server schemas:

  • In the Solution Explorer, right-click your project, click “Add”, and then click “Add Generated Items…”
  • In the “Add Generated Items – <Project Name> dialog box, select “Consume Add Service”, and then click “Add”.
  • Select the sqlBinding and properly configuring the URI

We will get the following error message:

Connecting to the LOB system has failed.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 – The remote computer refused the network connection.).

Connecting to the LOB system has failed: WCF-SQL Adapter

when we try to connect to the SQL Server configured.

Cause

This error may occur for several reasons like BizTalk Server cannot communicate with SQL Server machine because some firewall restrictions or SQL Server does not accept Remote Connections and so on.

However, in our case, we are talking about a standalone BizTalk machine that is trying to access a database in the local SQL Server.

Our problem was that by default what Microsoft could possibly configure wrong in terms of SQL Server protocols on the BizTalk Server developer image on Azure… is actually set up wrongly!

Connecting to the LOB system has failed: SQL Server 2016 Configuration Manager protocols

And as I described in my BizTalk Server Installation and configuration tutorial (see here), one of the important steps is to configure SQL Server Network Protocols, in special ensuring that TCP/IP is enabled and Shared Memory is disabled. You can see how to accomplish this using SQL Server Configuration Manager tool here.

The actual problem that was causing the connecting to fail while trying to connect to the LOB system, in this particular case the SQL Server is because the TCP/IP protocol is disabled.

Solution

To properly configure the protocols for SQL Server, especially the TCP/IP protocol, you should:

  • Press the “Windows key” to switch to Metro UI and type “SQL Server 20016 Configuration Manager” and click on “SQL Server 2016 Configuration Manager” option on Apps menu.
  • In SQL Server Configuration Manager windows, from the left-hand pane expand “SQL Server Network Configuration” option and then click “Protocols for MSSQLSERVER”
  • Verify that both “TCP/IP” and “Named Pipes” are enabled;
  • If not, right-click in the protocol, and then click “Enable”
  • Repeat to enable the other protocol if necessary.
  • Verify that “Shared Memory” is Disable.
  • If not, right-click Shared Memory, and then click “Disable”
  • In the left-hand pane, click “SQL Server Services”, right-click “SQL Server (MSSQLSERVER)”, and then click “Restart”.

Connecting to the LOB system has failed: SQL Server 2016 restart

  • Close SQL Server Configuration Manager.
  • Click “OK” and then “Apply”

After correctly configure the SQL Server protocols, again, especially the TCP/IP, you will be able to successfully connect and generate the SQL Server Schemas that you need for your BizTalk Server Solution.

The post WCF-SQL Adapter: Connecting to the LOB system has failed. A network-related or instance-specific error occurred while establishing a connection to SQL Server appeared first on SANDRO PEREIRA BIZTALK BLOG.

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

$
0
0

It is not the first time, neither will be the last that I encountered similar problems like this one or the same problem with earlier versions, we call it DLL hell (or nightmare) but I think that all BizTalk Administrator are familiar with it and vaccinated for the problem. Some months ago, while trying to communicate with an Oracle database within Visual Studio in a brand-new BizTalk Server 2016 Developer environment to generate the proper Schemas, we faced with the following Oracle.DataAccess problem:

Error saving properties.
(System.ArgumentException) Invalid binding.
(System.IO.FileNotFoundException) Could not load file or assembly ‘Oracle.DataAccess, Version=4.121.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.

Could not load file or assembly Oracle.DataAccess Version 4.121.1.0

Cause

When installing the Oracle WCF Adapter for BizTalk Server 2016 there is a design-time requirement to use Oracle.DataAccess Version 4.121.1.0.

BizTalk Server 2016 requires that specific Oracle.DataAccess version, however, us we were able to very on the GAC, the DLL that existed in our environment had a different version.

Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge

Note: depending on the BizTalk Server version that you are using, this the required Oracle.DataAccess version may change.

Solution

Trying to find the correct ODP.NET 11.2.0.1.2 version under Oracle website can be a challenge, so one of the easier and fast ways to solve this problem is using 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="4.121.1.0" newVersion="x.xxx.x.x" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

By doing this when BizTalk Server will look to the Oracle.DataAccess version which not exists in your environment, it will be redirected to the existing DLL version.

For example, in our case we used:

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

Just to be on the safe side, you should add this configuration in both 32 and 64-bit in .NET Framework 2.0 and 4.0 machine configuration files.

The post BizTalk Server 2016: Could not load file or assembly ‘Oracle.DataAccess, Version=4.121.1.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified. appeared first on SANDRO PEREIRA BIZTALK BLOG.

Viewing all 47 articles
Browse latest View live