It is always fun to return to one of my favorite topics: Errors and warnings, causes and solutions – aka Troubleshooting! Regardless of the technology, language, or service, we are using. In this case, this problem occurred when configuring the SFTP adapter in BizTalk Server 2020, which means BizTalk Server and WinSCP.
After installing and configuring the pre-requirements of the SFTP adapter according to the official documentation and using the BizTalk WinSCP PowerShell Installer, you can find it here. In our case, the latest official WinSCP version 5.19.2. We got the following error while trying to send a test message using the SFTP adapter:
A message sent to adapter “SFTP” on send port “SendPort2” with URI “sftp:/FTP-SERVER:22/%SourceFileName%” is suspended.
Error details: System.IO.FileLoadException: Could not load file or assembly ‘WinSCPnet, Version=1.12.0.12858, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ or one of its dependencies. General Exception (Exception from HRESULT: 0x80131500)
File name: ‘WinSCPnet, Version=1.12.0.12858, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ —> System.Exception: SFTP adapter requires WinSCP to be installed. Please refer http://go.microsoft.com/fwlink/?LinkID=730458&clcid=0x409 . —> System.IO.FileNotFoundException: Could not load file or assembly ‘file:///C:WINDOWSMicrosoft.NetassemblyGAC_MSILMicrosoft.BizTalk.Adapter.Sftpv4.0_3.0.1.0__31bf3856ad364e35WinSCPnet.dll‘ or one of its dependencies. The system cannot find the file specified.
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
at Microsoft.BizTalk.Adapter.Sftp.SftpHelper.AssemblyResolver(Object sender, ResolveEventArgs args)
— End of inner exception stack trace —
at Microsoft.BizTalk.Adapter.Sftp.SftpHelper.AssemblyResolver(Object sender, ResolveEventArgs args)
at System.AppDomain.OnAssemblyResolveEvent(RuntimeAssembly assembly, String assemblyFullName)
Server stack trace:
at Microsoft.BizTalk.Adapter.Sftp.SftpOutputChannel.Send(Message message, TimeSpan timeOut)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
Exception rethrown at [1]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IOutputChannel.EndSend(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.SendCallback(IAsyncResult result)
I was surprised by the error because this wasn’t the first time I had installed the SFPT Adapter. I have successfully performed this configuration in many clients and never found myself in a WinSCP DLL version nightmare.
Cause
As mentioned, I never had a version issue with the WinSCP DLLs if I installed it according to the documentation. That means depending on the BizTalk Server version and cumulative we have installed, we have to select the proper WinSCP version, for example:
With BizTalk Server 2020 (no CU installed), we need to use WinSCP 5.15.4
With BizTalk Server 2020 with CU1 and/or CU2 we need to use WinSCP 5.17.6
With BizTalk Server 2020 with CU3 and/or CU4 we need to use WinSCP 5.19.2
To put the SFTP Adapter, we need to copy the WinSCP.exe and WinSCPnet.dll to the BizTalk installation folder, normally C:Program Files (x86)Microsoft BizTalk Server. So, by the error description, this issue was clearly a DLL version issue.
In our case, we had BizTalk Server 2020 with CU4 and correctly installed the WinSCP 5.19.2. However, this version of WinSCP brings version 1.8.3.11614 of WinSCPnet.dll instead of version 1.12.0.12858, which is asking for. WinSCPnet.dll version 1.12.0.12858 is only available in WinSCP 5.21.5.
After some investigation, we detected that WinSCP version 5.21.5 was installed on the server, and because of that, the BizTalk Server SFTP adapter was trying to look for this version on C:WINDOWSMicrosoft.NetassemblyGAC_MSILMicrosoft.BizTalk.Adapter.Sftpv4.0_3.0.1.0__31bf3856ad364e35.
Notice that you don’t need to install any WinSCP software or GAC any WinSCP DLL on the BizTalk Server machine.
Solution
In the end, this is an issue that can be fixed easily. And there are many ways to solve this:
First approach: This may be the correct approach, is to:
Uninstall the WinSCP 5.21.5 version or any other version installed on the machine.
Make sure that there aren’t any WinSCPnet.dll in the GAC.
Note: We didn’t apply this approach because we were unsure who and what was using this WinSCP version.
Second approach: This second approach may not be 100% supported, but it still works like a charm.
We maybe also solve this problem by using an assembly redirect on the machine.config but I didn’t try it out.
Hope you find this helpful! So, if you liked the content or found it helpful and want to help me write more content, you can buy (or help buy) my son a Star Wars Lego!
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc.
He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community.
View all posts by Sandro Pereira
Recently I developed a custom file adapter called FILE-Z adapter that I blogged on the BizTalk360 blog. This is an adapter created from the original idea of my dear friend Nino Crudele. It is a custom File adapter capable of reading empty files.
You can see his original blog post here: BizTalk and zero byte file. And you can download the FILE-Z adapter here: FILE-Z adapter GitHub page.
But while I was searching about this adapter, I found an interesting blog post from Yan (Pamela) Yang where she described a different scenario. Some systems can create empty files without locking them. Then, they grab the files again and write some data to them. However, this behavior may cause problems with the default BizTalk Server FILE adapter. For example, the adapter may grab the file AFTER the system creates the empty file, but BEFORE the system attempts to write to it, causing integration issues. Or, in other cases, we may not want to pick up that empty files.
You may also know that the native FILE adapter released with BizTalk grabs and deletes all zero-byte (empty) files without triggering any associated processes. Instead, it logs a warning or error saying that:
The FILE receive adapter deleted the empty file “dir:<folder><file-name>” without performing any processing.
This behavior, according to Microsoft, is by design. Though you can argue that it is not consistent how different adapters treat empty files, e.g., FTP adapter can transfer empty files with no problem.
The File-RADITZ adapter is, kind of, the arch-enemy of the File-Z Adapter. This adapter doesn’t pick up or process empty (zero-byte) files. Instead, it leaves the empty files in the original folder.
I decided to create or recreate this adapter based on Yan Yang scenario just for fun and for mentoring how you can create your custom File adapter by making use of:
DotNet File Adapter sample source code that was available on previous versions of the BizTalk Server SDK
This adapter can be used as a Receive Adapter or as a Send Adapter.
Why the name File-RADITZ?
Well, I named the other adapter FILE-Z because it meant to mean File-Zero, but in reality, because I was a massive fan of Dragon Ball Z :). As I mentioned before, this adapter is, kind of, the arch-enemy of the File-Z Adapter. So, making the idea for a better name, I named it based on a memorable Dragon Ball villain: Raditz, that was one of the first enemy encounters in Dragon Ball Z.
How to install it?
If you want to install the BizTalk Server FILE-RADITZ Adapter, you need to:
Place the folder BizTalkFileRADITZAdapter on any location on your BizTalk Server box. I will recommend to put it in:
C:Program Files (x86)
Note: if you put in any other path you need to modify the StaticAdapterManagement.reg file
Access the folder and double-click on the StaticAdapterManagement.reg file
This will register the adapter to run under 32-bit host instances. To make it available also for 64-bits, you need to:
Click Start
Type %windir%SysWoW64cmd.exe in the search box and press enter
Run the same adapter registry (.reg) file from this command prompt
Now you just need to add this adapter to the BizTalk Server Administration Console:
Open BizTalk Administration Console by pressing the Windows key to switch to the Start menu, type BizTalk Server Administration or BizTalk, click the BizTalk Server Administration option from the Search window.
In the console left tree, expand BizTalk Server Administration à BizTalk Group à Platform Settings and then Adapters.
In the Adapter Properties
In the Name box, type a descriptive name for this adapter.
FILE-RADITZ
In the Adapter combo box, select the adapter from the drop-down that you want to add.
FILE-RADITZ
In the Description box, type a description for the adapter (this is optional).
BizTalk Server File Adapter that is able to process all files except empty (zero byte) files.
Click OK to complete the process of adding the adapter.
Where can you use it?
This version available on GitHub is currently compiled on .NET 4.7.2 and optimized for BizTalk Server 2020. Nevertheless, you can take this code and compile it in other versions of .NET and BizTalk Server. It will be 100% compatible.
Download
THIS ADAPTER IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND.
You can download the BizTalk Server FILE-RADITZ Adapter from GitHub here:
Surprisingly enough, or not, legacy systems can still be found across many organizations. IBM MQ is a family of message-oriented middleware products that IBM launched in December 1993. It was called MQSeries initially and was renamed WebSphere MQ in 2002 to join the suite of WebSphere products. In April 2014, it was renamed to IBM MQ.
We can mainly see the use and the need for integration with these products in banks systems. BizTalk Server provides two ways to communicate with IBM MQ:
By using the MQSeries built-in adapter that will act as a bridge between Microsoft BizTalk Server and IBM MQSeries servers:
The MQSeries adapter is available with the BizTalk Server installation. It supports transactional and non-transactional messaging by setting the Transaction Supported property in the MQSeries adapter transport properties
The MQSeries adapter uses the MQSAgent2 COM+ application to put/get messages into the IBM WebSphere Queue Manager
The MQSeries adapter requires IBM’s MQSeries Server for Windows to reside on the client system to communicate with an IBM WebSphere Queue Manager running on Windows or non-Windows. MQSeries Server for Windows is not a Microsoft product and must be obtained from your IBM WebSphere MQ program
By using the Host Integration Server (HIS) that provides a WCF Channel for MQ and BizTalk Adapter for MQ Series Client (MQSC) — depending on the version of BizTalk Server you are using that will support a variety of IBM WebSphere versions:
The MQSC adapter is a light-weight component of MQ that does not require the MQSeries Queue Manager run-time code to reside on a client system. The MQSC adapter is available in the BizTalk Adapters for Host Systems installation part of Host Integration Server (HIS). This adapter can connect to an IBM WebSphere Queue Manager on Windows or non-Windows. It also supports transactional and non-transactional messaging
This whitepaper’s goal is not how to install and configure MQSeries, neither compare the advantages or disadvantages of using this adapter compared to MQSC. Instead, this whitepaper’s focus is on improving the performance of the MQSeries adapter to better support low latency scenarios that most of the time are required in financial transactions.
Where I can download it
You can download the whitepaper here:
You can also find, download and enjoy several other free whitepapers of my own here:
I am currently doing many hybrid integrations, leveraging the capabilities of BizTalk Server and Logic Apps to meet the needs/requirements of my clients/projects. Some of these projects began initially to be completely on-premises, but as the projects grew and new needs emerged, the need to use some cloud services appeared like Power BI, Office365 (Teams, Outlook) and so on, became a reality. And these features are much easier to implement and have more productivity on Azure Logic Apps instead of BizTalk Server as there are already native connectors there.
And you have known that in reality there are several ways to implement this two bidirectionality communication between Logic App and BizTalk Server :
Sending messages from BizTalk Server to Azure Logic Apps
and receiving messages from Azure Logic Apps to BizTalk Server
like using HTTP requests or Azure Service Bus, and by doing so you can create robust and smart hybrid integrations. You may have to use one of these alternative implementations if you are using older versions of BizTalk Server.
The good news is that BizTalk Server 2016 has a better and more user-friendly way to make these hybrid connections. Instead of using HTTP requests, with BizTalk Server 2016 you can use the Logic Apps adapter to receive messages from an Azure Logic App or send messages to an Azure Logic App.
This whitepaper will give you a detailed understanding of the following:
Requirements to install Logic App adapter
Microsoft BizTalk Server Adapter for Logic Apps
On-premises data gateway
How to install and configure the Logic App Adapter
Where I can download it
The whitepaper is completely free and you can download it here:
I would like to take this opportunity also to once again say thanks to Lex Hegt for helping me reviewing this whitepaper especially for the incredible work of him correcting my horrible English and in this way make the document and my thoughts being readable.
I hope you enjoy reading this paper and any comments or suggestions are welcome.
You can also find, download and enjoy several other free whitepapers of my own here:
Following my last post and continuing on the pain points of BizTalk Server infrastructure tasks migration, I end up founding another interesting error: WCF-Custom Reason: System.ArgumentException: An item with the same key has already been added.
Again, we indeed did more than a simple migration, we take this opportunity to improve our solutions and/or BizTalk Server environment to update our applications to the new the new available features. In terms of WCF-SAP Adapter, we are no longer using traditional RFC and we will be starting using SAP .NET Connector (NCo). Despite WCF-SAP adapter will continue to support both the RFC SDK and the SAP .NET Connector, SAP has announced deprecation of its classic RFC SDK (no longer be supported after March 31, 2016) and because of that, it should be used anymore.
While trying to connect our BizTalk Server Receive Location to SAP in order to listen to incoming messages, we initially got this error message:
The Messaging Engine failed to add a receive location “WcfReceiveLocation_SAPBinding_IdocDELVRY05V3R700_Custom” with URL “sap://CLIENT=400;LANG=EN;@a/SERVERNAME/00?ListenerGwServ=sapgw00&ListenerGwHost=LISTENERHOST&ListenerProgramId=BTS_LIST&RfcSdkTrace=False&AbapDebug=False ” to the adapter “WCF-Custom”. Reason: “System.ArgumentException: An item with the same key has already been added.
at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Microsoft.Adapters.SAP.NCo.RfcServerConnection.Open(RfcClientConnection conn)
at Microsoft.Adapters.SAP.SAPInboundContract.InitializeRfcServerConnectionNCo(String connectionArguments)
at Microsoft.Adapters.SAP.SAPInboundContract.StartListener(String[] listenerActions, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterChannelListener`1.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiveEndpoint.Enable()
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiveEndpoint..ctor(BizTalkEndpointContext endpointContext, IBTTransportProxy transportProxy, ControlledTermination control)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiver`2.AddReceiveEndpoint(String url, IPropertyBag adapterConfig, IPropertyBag bizTalkConfig)”.
The reason why I’m saying that is that each time I restarted the BizTalk Server Host Instances, the error that I got the first time I try to enable the port was this service ‘?’ unknown error. Afterward, whenever I tried to enable this port, I would receive this new error:
System.ArgumentException: An item with the same key has already been added
Why this is happening for me is a mix of a small bug and consistency, let me explain better:
Why consistency? This because in fact, you cannot have two SAP Receive Locations listening to the same SAP endpoint/SAP Listener Program Id.
Actually, this should be when this error would normally occur.
Why a small bug? Because in fact there isn’t any Receive location enable for that specific SAP endpoint/SAP Listener Program Id. What is happening is that despite the error and the receive location became automatically disable it somehow stores in memory that SAP endpoint/SAP Listener Program Id
Solution
The solution is very simple and stupid:
Restart the host instance that is running that Receive Location
After that, this problem goes away, but make sure you solve all the problems, or this may happen again.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
I’m currently migrating a BizTalk Server infrastructure from BizTalk Server 2013 R2 to BizTalk Server 2016, this is a simple task to do in terms of BizTalk Server Applications, or BizTalk Server solutions. However, migrating or in fact, creating a new environment always brings challenges in terms of connectivity and/or proper configurations. SAP.Middleware.Connector.RfcCommunicationException: LOCATION CPIC (TCP/IP) on local host BTSSERVERNAME with Unicode, ERROR service ‘?’ unknown error is one of this cases!
We indeed did more than a simple migration, we toked this opportunity to improve our solutions and/or BizTalk Server environment to update our applications to the new the new available features. In terms of WCF-SAP Adapter, we are no longer using traditional RFC and we will be starting using SAP .NET Connector (NCo). Despite WCF-SAP adapter will continue to support both the RFC SDK and the SAP .NET Connector, SAP has announced deprecation of its classic RFC SDK (no longer be supported after March 31, 2016) and because of that, it shouldn’t be used anymore.
While trying to connect our BizTalk Server Receive Location to SAP in order to listen to incoming messages, we initial got this error message:
The Messaging Engine failed to add a receive location “IN_WCF_SAP_LISTENER_BTS” with URL “sap://CLIENT=400;LANG=EN;@a/SERVERNAME/00?ListenerGwServ=sapgw00&ListenerGwHost=LISTENERHOST&ListenerProgramId=BTS_LIST&RfcSdkTrace=False&AbapDebug=False” to the adapter “WCF-Custom”. Reason: “SAP.Middleware.Connector.RfcCommunicationException:
LOCATION CPIC (TCP/IP) on local host BTSSERVERNAME with Unicode
ERROR service ‘?’ unknown
TIME Fri Nov 23 13:47:22 2018
RELEASE 721
COMPONENT NI (network interface)
VERSION 40
RC -3
DETAIL NiErrSet
COUNTER 3
at SAP.Middleware.Connector.RfcServer.DoStart(Boolean logErrors)
at SAP.Middleware.Connector.RfcServer.Start()
at Microsoft.Adapters.SAP.NCo.RfcServerConnection.Open(RfcClientConnection conn)
at Microsoft.Adapters.SAP.SAPInboundContract.InitializeRfcServerConnectionNCo(String connectionArguments)
at Microsoft.Adapters.SAP.SAPInboundContract.StartListener(String[] listenerActions, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterChannelListener`1.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Dispatcher.ChannelDispatcher.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiveEndpoint.Enable()
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiveEndpoint..ctor(BizTalkEndpointContext endpointContext, IBTTransportProxy transportProxy, ControlledTermination control)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfReceiver`2.AddReceiveEndpoint(String url, IPropertyBag adapterConfig, IPropertyBag bizTalkConfig)”.
The receive location “IN_WCF_SAP_LISTENER_BTS_ DV” with URL “sap://CLIENT=400;LANG=EN;@a/SERVERNAME/00?ListenerGwServ=sapgw00&ListenerGwHost=LISTENERHOST&ListenerProgramId=BTS_LIST&RfcSdkTrace=False&AbapDebug=False” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.
Cause
The first thing you need to know is that this error is not related to the fact that we are now using the SAP .NET Connector (NCo). This error will still occur if you change back to the classic RFC.
The basic steps if of course to see if we have connectivity and proper access to SAP, and because we were in DEV environment a good way to test this is to Add WCF-SAP Adapter Metadata to a BizTalk Project inside Visual Studio
In your Visual Studio BizTalk project, in Solution Explorer, right-click your project, click Add, and then click Add Generated Items.
You will have the same look and fill as creating a Receive Port on the Administrative Console with the advantage of being able to navigate the under the SAP object structure. This way you can test connectivity and access to the proper resources.
In our case, everything worked well. We were able to connect and generate the schemas.
However, all of this is not enough. For the WCF-SAP adapter to work properly in runtime you also need to configure, somewhere in the BizTalk Server machine the TCP port where the SAP adapter will be looking for these connections, because this property is not exposed through the BizTalk Server WCF-SAP Adapter GUI port (send or receive) configuration.
In our case, the .NET Connector need to know the port of the message server. This is also very common to happen in load balancing situations.
Solution
In order to specify this TCP port, you need to modify the ‘services’ file in each BizTalk Server machine, normally in:
C:Windowssystem32driversetcservices
To include the following entry:
MSHOST 1234/tcp # SAP ENV System Message Server Port
Where:
MSHOST is your Gateway server, in our case sapgw00
And 1234 is your message server port, in our case: 3300
Just for curiosity, BizTalk isn’t the only that will use these values and this ‘services’ file. SAPGUI will also use these same values when connecting to SAP systems.
After we did this configuration, we were able to connect and start receiving messages from our SAP system.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
Another day, another error to report – still have plenty of them in my backlog to be published, they are an “easy and quick way” to publish something in my blog when I really don’t have much free time to write something different. Today is about “This is because either (a) ambient transaction is present and the TNS alias is longer than 39 characters” error message that I got when I was initially trying to connect for the first time to ORACLE database to insert some data:
Microsoft.ServiceModel.Channels.Common.MetadataException: Metadata resolution failed for OperationId: “http://Microsoft.LobServices.OracleDB/2007/03/STGADMIN/Table/TRANSACTIONS/Insert”. —> Microsoft.ServiceModel.Channels.Common.ConnectionException: Due to an Oracle Client limitation, the adapter failed to open a connection. This is because either (a) ambient transaction is present and the TNS alias is longer than 39 characters, or (b) ambient transaction is present and a non-TNS based URI was used. To resolve this, use a TNS alias to connect to Oracle and make sure it is not more than 39 characters.
at Microsoft.Adapters.OracleDB.OracleDBConnection.OpenConnection(OracleCommonExecutionHelper executionHelper)
— End of inner exception stack trace —
Server stack trace:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceCh.
Followed by other similar warning messages:
A message sent to adapter “WCF-Custom” on send port “INSERT_PAYMENTS_WCFORACLE” with URI “oracledb://IP-ADDRESS:PORT-NUMBER/PATH” is suspended.
Error details: Microsoft.ServiceModel.Channels.Common.MetadataException: Metadata resolution failed for OperationId: “http://Microsoft.LobServices.OracleDB/2007/03/STGADMIN/Table/PAYMENTS/Insert”. —> Microsoft.ServiceModel.Channels.Common.ConnectionException: Due to an Oracle Client limitation, the adapter failed to open a connection. This is because either (a) ambient transaction is present and the TNS alias is longer than 39 characters, or (b) ambient transaction is present and a non-TNS based URI was used. To resolve this, use a TNS alias to connect to Oracle and make sure it is not more than 39 characters.
at Microsoft.Adapters.OracleDB.OracleDBConnection.OpenConnection(OracleCommonExecutionHelper executionHelper)
— End of inner exception stack trace —
Server stack trace:
at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
at System.ServiceModel.Channels.ServiceChannel.EndRequest(IAsyncResult result)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.Channels.IRequestChannel.EndRequest(IAsyncResult result)
at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.RequestCallback(IAsyncResult result)
Non-TNS based URI is not supported under an ambient transaction. If you have to use transactions, you should use the TNS alias.
Note: TNS Alias needs to be less than 39 characters.
Solution
To solve this problem, you need to:
Open the send port properties, by double-clicking on the port;
Click on “Configure…” button under Transport
On the Transport Properties window, select the “Message” tab and then uncheck the “Use Transaction” box under Transactions
If you try to resend the message this problem should be solved. Additionally, if this error still persists, you should change the following properties in the oracleDBbinding:
“enableBizTalkCompatibilityMode” = True (this is set to false per default)
And/or “useAmbientTransaction” = False
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
In the spirit of documenting all possible and imaginary errors, let’s address today a classic one: File transport does not have read/write privileges for receive location “DRIVE:FOLDER NAME”.
This happens more than you may think, and today after finish creating a backup port for testing a new process while I was trying to Enable the File receive location I got the following errors:
File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”.
Followed by other similar warning messages:
The Messaging Engine failed to add a receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” to the adapter “FILE”. Reason: “File transport does not have read/write privileges for receive location “C:BizTalkPortsIN_POLLING”. “.
The receive location “POLLING_FILE” with URL “C:BizTalkPortsIN_POLLING*.xml” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.
Cause
As I said before this is a classic error, the reason is quite obvious and the error message clearly identifies the origin of the problem.
The problem is that the user that is running the BizTalk Server host instance(s) don’t have read/write privileges in that specific folder.
Solution
To solve this problem, you need to give readwrite privileges for the user that is running BizTalk Server Host Instance, in my case “BTSHostSrvc”, into that specific folder. For that you need to:
From the file system, access to the folder in question and then right-click on the folder and select the “Properties” option;
If attribute “Read-only (only applies to files in folder)” is enabled (selected), disable it (unselect);
Then go to the “Security” tab and then click “Edit…” button and then “Add…” button
Search for the user that is running the BizTalk Server Host Instance and then click “OK”;
For that specific user give read and write access;
In my case, because this was/is a “BizTalk process” folder, I gave “Full control”
At the click “OK” and “OK” once again.
Once you give access to the user this classic problem is going away… until the next time!
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
After many requests and many postponements, due to my unavailability and free time to take these tasks, BizTalk Scheduled Task Adapter is finally officially available and optimized for BizTalk Server 2016 on GitHub!
This became more critical because Codeplex closed and community members were not finding mainly the installation files so I was getting a lot of emails requesting them. Note that despite Codeplex is closed you can still download the source code from the archive.
At the moment is only available the installation files of BizTalk Scheduled Task Adapter v6.0 for BizTalk Server 2016 and the following reported issue was solved:
In some scenarios, in the first trigger event, multiple messages were sent at the same time – Solved
You can download this “new” version of the adapter in BizTalk Scheduled Task Adapter from GitHub:
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.
Soon I will add the source code for BizTalk Server 2016 and the same for previous versions: BizTalk Server 2013 R2, BizTalk Server 2013, BizTalk Server 2010, and so on.
Question?
Should I do a BizTalk Scheduled Task Adapter commercial version that will guarantee full support to this adapter (reported bugs and/or issues quietly fixed) and new features?
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
This week while configuring and optimizing a brand-new BizTalk Server 2016 environment we got the following error message while trying to configure register the WCF-SQL Adapter in the BizTalk Server Administration console:
Creation of Adapter WCF-SQL Configuration Store entries failed. Access denied. See the event log (on computer ‘SQL-SERVER’) for more details.
(sorry the picture quality, it was taken with my cell phone)
Despite I was a member of BizTalk Administration group, I didn’t have remote access to the SQL Server machine that was managed by another team so I couldn’t go there to check it out. Nevertheless, I reach that team (SQL and sysadmins) already with a possible solution that it turned out to be correct.
Cause
Many of the times these types of issues indicate or lead us to believe that there are problems associated with MSDTC. Or is not properly configured, Windows Firewall may be blocking DTC communications or in HA environment’s SSO is not clustered and may be offline.
All these possibilities should be investigated. However, if any of the points mentioned above were, for this particular case, a probable cause for this problem, it should have already manifested itself when the team pre-installed the environment and they did install the environment without encountering any problems.
The only difference between the installation and now my configuration was that these tasks were made by different users!
It is important to mention that, the user that is trying to registering an Adapter using the BizTalk Server Administration Console, need to have permissions to the SSO Database in order to register its properties so that he can store and retrieve the properties at design time and runtime.
And that is one of the reasons for why the “BizTalk Server Administrators” group should be a member of the “SSO Administrators” group.
BizTalk administrations are responsible for configuring all the components of BizTalk and many of them need to interact with SSO Database.
The people/team that was responsible to install BizTalk Server, they were members of BizTalk Server Administration, SSO Administration and some of them System Administrations and that was the reason why they didn’t get this problem or similar problems. The reason for the problem I faced was because:
My user was a member of BizTalk Server Administrators and local admin only. But the BizTalk Server Administrators wasn’t member of SSO Administration group.
Solution
To solve this problem, you may have two options:
Add my user to the SSO Administrators group.
Not recommended because in my opinion is more difficult to manage user access rights if you add them to each individual group.
Or add the “BizTalk Server Administrators” as a member of the “SSO Administrators” group.
After my user or the “BizTalk Server Administrators” group was added as a member of the “SSO Administrators” group, I was able to register the adapter.
Note: this problem can happen with any adapter you are trying to register.
Author: Sandro Pereira
Sandro Pereira lives in Portugal and works as a consultant at DevScope. In the past years, he has been working on implementing Integration scenarios both on-premises and cloud for various clients, each with different scenarios from a technical point of view, size, and criticality, using Microsoft Azure, Microsoft BizTalk Server and different technologies like AS2, EDI, RosettaNet, SAP, TIBCO etc. He is a regular blogger, international speaker, and technical reviewer of several BizTalk books all focused on Integration. He is also the author of the book “BizTalk Mapping Patterns & Best Practices”. He has been awarded MVP since 2011 for his contributions to the integration community. View all posts by Sandro Pereira
