BizTalk WCF-SQL Error: System.NotSupportedException: The SqlDbType “” is not supported

BizTalk WCF-SQL Error: System.NotSupportedException: The SqlDbType “” is not supported

Recently while I was testing an integration solution on a client that uses WCF-SQL to insert data on a SQL Server database I got the following error:

System.NotSupportedException: The SqlDbType “” is not supported. Modify your table, view, stored procedure, or function definition to avoid having parameters or columns of this type.

This was a surprise since everything was working properly in the development environment.

Cause

In this solution, we were doing bulk insert on a SQL Server database by using a User-Defined Types as the input to the stored procedure, in our case a User-Defined Table Type. There are other ways to do a SQL Server bulk insert or update in BizTalk Server but definitely, this is the best approach. And this is one of the reasons why we are getting on the error message with the keyword: SqlDbType.

This problem occurs because the user account that you used to access the database, in my case the BizTalk Host Instance Account, don’t have permissions on the User-Defined Type associated to the Store procedure that we were invoking.

Solution

To solve this issue, you must give access to the user, in my case BizTalk Host Instance Account to properly execute the stored procedure, you must:

  • Open SQL Server Management Studio and connect to your server.
  • In the Object Explorer, select and expand the desired database and expand the Security folder and then the Users.
  • Right-click on the User, BizTalk Host Instance Account, and choose Properties.
  • On the Database User windows, choose the Owned Schemas tab, and then on the Schemas owned by this user panel select the schema bind to your User-Defined Table Type.
    • In our case: Material
  • Click OK and try again to send the data to your SQL Server. It should work.

The post BizTalk WCF-SQL Error: System.NotSupportedException: The SqlDbType “” is not supported appeared first on SANDRO PEREIRA BIZTALK BLOG.

Revisiting “The Get-AzLogicApp command was not found”?

Revisiting “The Get-AzLogicApp command was not found”?

Last week, when preparing for a deployment, I bumped into this error again. As from my previous post, it could be easily fixed with a PowerShell module install.

You can review it here: https://www.linkedin.com/pulse/get-azlogicapp-command-found-pedro-almeida/?trackingId=LYhay%2BdvR7ieQ0XnCy9q0Q%3D%3D

But this time, the script was already fixed. Nothing had changed, as far as I knew. The last build and publish was in September, no errors there.

So what happened that killed my build?

It couldn’t be the Az module updates, because we were forcing the version. There had been several updates, so could this be it?

I tried to force a newer version, like 2.0.0, but still failed to execute the command. I even restricted the script to use only the command I needed, that was the CallbackUrl.

After a few other failures, my thinking was, “this can’t be the problem, the script was executing without issues, so it has to be something else.”

So I took another look at my pipeline. It was the same as before… Azure Powershell task to remove AzureRM, install Az module and Azure CLI task to execute the scri… wait!

Could this be the problem?

I switched the tasks and re-queued the pipeline.

And success! No more errors.

Azure CLI has received some updates in the past weeks, and the build I had before was 2.0.16 (Core 2.11.0) compared to 2.1.0 (Core 2.18.0) was running in these failed pipeline runs.

I looked into the Azure CLI release notes, but found nothing referring the LogicApp commands or Az.LogicApps.

This time, I can’t find a proper explanation for this error, but I’m suspecting some update broke the ability to run these Az module commands with Azure CLI or the Az.LogicApps commands specifically.

The post Revisiting “The Get-AzLogicApp command was not found”​ appeared first on SANDRO PEREIRA BIZTALK BLOG.

A fish out of water: PowerShell – The term ‘Invoke-Sqlcmd’ is not recognized as the name of a cmdlet, function, script file, or operable program.

A fish out of water: PowerShell – The term ‘Invoke-Sqlcmd’ is not recognized as the name of a cmdlet, function, script file, or operable program.

It has been a long time since I go off-topic on my main blog topic: Enterprise Integration. Nevertheless, everything that I wrote is somehow related to my daily job, and if you keep an eye on my blog, you will know that I like using PowerShell for scripting and automate several tasks.

Today while I was implementing a PowerShell script that I use in several clients I was surprised by this error: Invoke-Sqlcmd : The term ‘Invoke-Sqlcmd’ is not recognized as the name of a cmdlet, function, script file, or operable program.

The full warning message would be:

Invoke-Sqlcmd : The term ‘Invoke-Sqlcmd’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included,
verify that the path is correct and try again.
At C:pathpowershellscript.ps1:7 char:14

+ $sqlresult = Invoke-Sqlcmd -Query “SELECT TOP 1 …
+              ~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Invoke-Sqlcmd:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

The error message is very clear, and the problem is quite simple to solve… except if your machine doesn’t have connectivity to the internet. But let’s first explain the issue.

Cause

As I told you before, The error message is very clear, and the problem is quite simple to solve, the SQL Server PowerShell module is not installed on the machine.

Many may think that SQL Server Management Studio is a requirement or by installing it may solve this problem, but that is not true. In fact, SQL Server Management Studio (SSMS), doesn’t install the PowerShell module.

Solution 1: System with access to the Internet

If the machine where this issue is happening has access to the internet, then you just need to install the SQL Server PowerShell module by executing the following script:

Import-Module sqlserver

Note: You should run PowerShell as an Administrator

Solution 2: System without access to the Internet

However, if your machine doesn’t have access to the internet you will get the folowing error idf you try to execute the above script:

Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
Unable to download the list of available providers. Check your internet connection.
PackageManagementInstall-PackageProvider : No match was found for the specified search criteria for the provider ‘NuGet’. The package provider requires ‘PackageManagement’ and ‘Provider’
tags. Please check if the specified package has the tags.
At C:Program FilesWindowsPowerShellModulesPowerShellGet1.0.0.1PSModule.psm1:7468 char:21
+ …     $null = PackageManagementInstall-PackageProvider -Name $script:N …
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception
    + FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider
PackageManagementImport-PackageProvider : No match was found for the specified search criteria and provider name ‘NuGet’. Try ‘Get-PackageProvider -ListAvailable’ to see if the provider exists on the system.
At C:Program FilesWindowsPowerShellModulesPowerShellGet1.0.0.1PSModule.psm1:7474 char:21
+ …     $null = PackageManagementImport-PackageProvider -Name $script:Nu …
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (NuGet:String) [Import-PackageProvider], Exception
    + FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProvider
Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
Unable to download the list of available providers. Check your internet connection.
PackageManagementGet-PackageProvider : Unable to find package provider ‘NuGet’. It may not be imported yet. Try ‘Get-PackageProvider -ListAvailable’.
At C:Program FilesWindowsPowerShellModulesPowerShellGet1.0.0.1PSModule.psm1:7478 char:30
+ … tProvider = PackageManagementGet-PackageProvider -Name $script:NuGet …
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Microsoft.Power…PackageProvider:GetPackageProvider) [Get-PackageProvider], Exception
    + FullyQualifiedErrorId : UnknownProviderFromActivatedList,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPackageProvider

To solve this issue you need to:

  • From an Internet-connected computer, execute the following script
Save-Module sqlserver -path c:temp

Note: You can set a different path to save the module.

  • The above command will save the SQL Server PowerShell module to the directory you set on a folder called SqlServer
    • In my case, c:tempSqlServer
  • Then, copy that whole directory to your target computer(s) to the following folder:
    • C:Program FilesWindowsPowerShellModules

By coping to this folder it will make the module available to all users.

If you are not sure about the path, you can always check the paths by exxecuting the following script:

$env:psmodulepath.split(";")

The post A fish out of water: PowerShell – The term ‘Invoke-Sqlcmd’ is not recognized as the name of a cmdlet, function, script file, or operable program. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BAM Portal: You are not authorized to view this page due to invalid authentication headers.

BAM Portal: You are not authorized to view this page due to invalid authentication headers.

I know, BAM Portal is deprecated in BizTalk Server 2020 but it is still available and until there is no better alternative – you can always use BizTalk360 – it is better than nothing.

Yesterday while I was once again playing with BAM in BizTalk Server 2020 I ended up having the following error message while trying to access to BAM Portal:

HTTP Error 401.2 – Unauthorized

You are not authorized to view this page due to invalid authentication headers.

That was a bit strange since normally Everyone has access to BAM Portal, what normally can happen is that they don’t see any BAM View to explore.

Cause

For me, it was clear that this error was somehow related to the user-authentication methods/protocols installed on IIS. So I went to check the available user-authentication methods on IIS and realized that was missing the most critical method for BAM Portal to work: Windows Authentication.

BAM Portal requires Windows Authentication to work correctly.

This error is not related

Solution

This issue is very simple to fix. Windows Authentication was not available as an option, so we have to install it, and to do that you need to:

  • Start by running the Server Manager, if it is not already open, on the Windows Start menu, click the Server Manager option.
  • Under the Manage menu, select Add Roles and Features (or press Add roles and features under the Dashboard panel).
  • On the Before You Begin screen, click Next.
  • On the Installation Type screen, select Role-based or feature-based installation and click Next.
  • On the Server Selection screen, select the appropriate server, leave the default options, and click Next.
  • On the Server Roles screen, expand the Web Server (IIS) > Web Server > Security options.
    • Make sure that you select Windows Authentication option
    • Click Next.
  • On the Features screen, click Next.
  • On the Confirmation screen, click Install

Now if you try you will be able to successfuly access to BAM Portal

The post BAM Portal: You are not authorized to view this page due to invalid authentication headers. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”

BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”

Until now, I usually have used the Logic App adapter to send messages to Azure Logic Apps and extend the BizTalk Server capabilities with the Azure Services. Yesterday, once I was trying the inverse capabilities, i.e., receiving a message from Logic App into BizTalk Server using the Logic App Adapter and, of course, the BizTalk Server Connector available on Logic App. I was surprised with the following error while I was trying to access the exposed service to receive messages from Logic App:

Receive location for address “/LogicAppTestServoce/Service1.svc” not found. (The BizTalk receive location may be disabled.)

This is a common error. It means that the Receive Location doesn’t exist or it is disabled. So I went to the BizTalk Server Administration Console and Enabled the Receive Location, but it automatically disabled again.

Once I check the Event Viewer for errors I found the 3 following errors:

The Messaging Engine encountered an error when creating the receive adapter “LogicApp”. The Assembly is: “Microsoft.BizTalk.Adapter.LogicApp.Runtime.LogicAppReceiver, Microsoft.BizTalk.Adapter.LogicApp.Runtime”. The error occurred because the component does not implement the mandatory interface “IBTTransportControl”.

The Messaging Engine failed to add a receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” to the adapter “LogicApp”. Reason: “80070057”.

The receive location “POC_LOGICAPP_TO_BIZTALK_LA” with URL “/LogicAppTestService/Service1.svc” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.

Cause

There is a critical bug in the default installation of the Logic App adapter that will affect the process of receiving messages from Logic Apps using the BizTalk Server Connector.

The Logic App Receive handler, or what we usually call the Logic App Receive adapter, is, by default, configured to use the default In-Process Host, normally the BizTalkServerApplication, in this case, as you saw in the picture bellow BizTalkServerReceiveHost.

Like what happens with the HTTP adapter, the Logic App Adapter is one of the adapters that support two-way communications. Still, unlike other adapters, this adapter has two characteristics that define it:

  • The Logic App Receive Adapter that is responsible for delivering messages to BizTalk is, in fact, a WCF Service that runs inside Internet Information Services (IIS).
  • And for that reason, it must be configured in IIS – it is not there out-of-the-box.

This means that when we create and configure a receive location that uses the Logic App adapter inside the BizTalk Server Administration Console, this receive location uses an application within IIS.

So, if you leave this Logic App Adapter default configuration, you will end up having the above errors when trying to activate a Receive Location. This happens assigned because the Receive handler is associated with the In-process Host and it should be bound to the Isolated Host.

Solution

To fix this bug we need to:

  • Remove the adapter from all assigned send ports and receive locations in my applications
    • Therefore, it is essential to do this immediately after the installation and configuration of your BizTalk Server environment. Otherwise, it will affect your existing application that uses the Logic App adapter to send messages to Logic Apps.
  • Download the BizTalk Server 2020: Scripts to Fix Logic App Adapter installation available on GitHub.
  • Execute the RemoveLogicAppAdapter.vbs script to un-register the Logic App adapter from the BizTalk Server Configuration Console.
  • Execute the AddLogicAppAdapter.vbs script to properly register the Logic App adapter from the BizTalk Server Configuration Console.

The post BizTalk Server 2020 Logic App Adapter: The Messaging Engine failed to add a receive location “Receive Location” with URL “…/Service1.svc” to the adapter “LogicApp”. Reason: “80070057” appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 Configuration: Error validating the SSIS Catalog database. Please ensure SQL Server Integration Services is installed on the local machine and SSIS Catalog is created on target SQL Server

BizTalk Server 2020 Configuration: Error validating the SSIS Catalog database. Please ensure SQL Server Integration Services is installed on the local machine and SSIS Catalog is created on target SQL Server

Following my last blog post and while I was trying to fix some issues regarding a BizTalk Server 2020 installation and configuration provided by my intern as is learning process. We end up solving some critical problems that allow us to install the platform’s most important components. Nevertheless, several components like BAM Tools, BAM Portal and BizTalk EDI/AS2 Runtime failed to configure:

Once, we inspect the logfile provide the the BizTalk Server Configurarion Wizard we found the following error message:

[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BAM Tools] Failed to configure with error message [Feature is skipped due to failed validation.  Please go to Custom Configuration to fix the validation error.

Validation Error: <Exception Message=”Error validating the SSIS Catalog database. Please ensure SQL Server Integration Services is installed on the local machine and SSIS Catalog is created on target SQL Server.” Source=”BAMTools” HelpID=”idsErrorValidateSSISCatalogDatabase”><Exception Message=”SSIS Catalog (SSISDB) does not exist on server BTS2020LABAVMRG. Please create SSIS Catalog.” Source=”Microsoft.BizTalk.Bam.CfgExtHelper.ToolsHelper” HelpID=”error_SSISCatalogNotExists”/></Exception>]

[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BAM Portal] Failed to configure with error message [The Configuration of Feature ‘BAM Portal’ failed because the dependent Feature ‘BAM Tools’ was not configured. ]

[2020-11-10 22:17:18:0674 Error Configuration Framework]Feature: [BizTalk EDI/AS2 Runtime] Failed to configure with error message [Feature is skipped due to dependent feature (BAM Tools) failed to configure correctly.]

Three distinct errors but the last two are a sequence of the first one, all of them are related to the same cause.

Cause

SSISDB was automatically created during the BizTalk Server configuration process on previous versions if we enable BAM Portal. However, BAM Portal was deprecated in this new BizTalk Server version, and the configuration process no longer created the SSIS Catalog. Instead, we need to create the catalog manually.

If you don’t create the SSIS Catalog manually, you will not be able to configure BAM Portal. Nevertheless, you can always perform this operation whenever you think is required, and after that, configure BAM Portal.

Make sure you also configure SQL Server Database Mail feature if you wish to configure BAM Alerts on your BizTalk Server 2020 environment

Solution

The solution is very simple, we need to manually create the catalog by using the following instructions:

  • Open SQL Server Management Studio and connect to the SQL Server Database Engine.
  • In Object Explorer, expand the server node, right-click the Integration Services Catalogs node, and then click Create Catalog.
  • On the Create Catalog window, do the following configuration and click OK.
    • Select Enable CLR Integration option.
    • Enter a password to protect the encryption key.

And run the BizTalk Server Configuration again. At the end you will be able to configure all BizTalk Server components.

The post BizTalk Server 2020 Configuration: Error validating the SSIS Catalog database. Please ensure SQL Server Integration Services is installed on the local machine and SSIS Catalog is created on target SQL Server appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Configuration error: Cannot create file ‘C:pathname.mdf’ because it already exists. Change the file path or the file name, and retry the operation

BizTalk Server Configuration error: Cannot create file ‘C:pathname.mdf’ because it already exists. Change the file path or the file name, and retry the operation

As the learning process’s path, all my interns or new team members, regardless of what technologies they will be using more, one of the first things they will do is create a BizTalk Server development environment from scratch. Yes, all my team members will have skills in all Integration technologies, BizTalk Server, Logic Apps, Service Bus, APIM, and the list goes on and on.

I don´t mind or care if you get it right the first time or not. Sometimes it is with failures that we learn best and more. And I find it curious that with these exercises, they will find problems that I would never imagine happening, so sometimes it is a learning process and continuous improvement for both or the team.

This is one of these cases. My recent team member, while he was trying to configure BizTalk Server using the BizTalk Server Configuration wizard, was getting a failure in all the components immediately:

As he did not understand why this problem was happening, he asked me for help. Once we analyze the log file generated by the configuration wizard, we saw this error:

[2020-11-10 22:08:14:0631 Error Configuration Framework]Feature: [Enterprise SSO] Failed to configure with error message [<Exception Message=”Failed to create the SQL database ‘SSODB’ on SQL Server ‘BTS2020LABAVMRG’ (with SSO Administrator account ‘SSO Administrators’).” Source=”SSO” HelpID=””><Exception Message=”(0xC0002A21) An error occurred while attempting to access the SSO database. ” Source=”SSO” HelpID=””><Exception Message=”An error occurred while attempting to access the SSO database. See the event log (on computer ‘BTS2020LABAVMRG’) for more details. ” Source=”SSO” HelpID=””/></Exception></Exception>]

Basically, this error message does not show any clue or cause as to why this problem is happening. Nevertheless, it will point to you a source to see more details about this issue: the event viewer.

Once we chech the event viewer we got a very clear error message:

Cannot create file ‘C:Program FilesMicrosoft SQL ServerMSSQL15.MSSQLSERVERMSSQLDATASSODB.mdf’ because it already exists. Change the file path or the file name, and retry the operation.

Cause

The reason for this error to happen is clear. The BizTalk Server configuration wizard is trying to create the database files on the default SQL Server folders, but they already exist.

This error happened because my team member initially didn’t install all the required SQL Server components correctly. Once he was trying to add new features to an existing instance, he accidentally created another SQL Server instance.

After that, he uninstalled all the SQL Server instances and appropriately installed all the components, at least for now, let’s assume so. Nevertheless, while he was trying to do a Basic Configuration, he got that “strange” error.

Thru the SQL Server Management Console, we couldn’t see these databases, not only SSO as the error description, but also with all other BizTalk Server databases. But once we saw that folder, we realize that the uninstalls did not delete BD files created before from the hard drive.

Solution

The solution is very simple, delete all the Unnecessary files from that folder, like:

  • SSO
  • SSO_log
  • BizTalkDTADb
  • BizTalkDTADb_log
  • BizTalkMgmtDb
  • BizTalkMgmtDb_log
  • BizTalkMsgBoxDb
  • BizTalkMsgBoxDb_log
  • BizTalkRuleEngineDb
  • BizTalkRuleEngineDb_log

And run the BizTalk Servr Configuration again. At the end you will be able to configure BizTalk Server.

Hey… but there still errors over there. Indeed, there are, but I will leave that to another post that will be published very soon. However, this blog post’s original error was solved, and we were able to configure the required and critical BizTalk Server components: SSO, Group, and BizTalk Runtime.

The post BizTalk Server Configuration error: Cannot create file ‘C:pathname.mdf’ because it already exists. Change the file path or the file name, and retry the operation appeared first on SANDRO PEREIRA BIZTALK BLOG.

Error while calling Logic App thru PowerShell: The underlying connection was closed: An unexpected error occurred on a send.

Error while calling Logic App thru PowerShell: The underlying connection was closed: An unexpected error occurred on a send.

This week while I was implementing a BizTalk Server monitoring solution using:

  • PowerShell: for querying the environment;
  • Logic Apps: creating the flow logic for notifying the non-compliances
  • Function App: to convert the JSON object to HTML

while I was trying to invoke a Logic App with a Request trigger from PowerShell:

{
$jsonDoc = [pscustomobject]@{
    Monitor = "Disk Space Monitoring"
    Client = "Sandro Pereira"
    Environment = "DEV"
    Disks = $diskNode
}

Invoke-WebRequest -Uri 'https://{URi}.logic.azure.com:443/workflows/{guid}/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={sig}' -Method POST -Body ($jsonDoc|ConvertTo-Json) -ContentType "application/json"
}

I got the following error:

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send.
At C:BizTalkApplicationsMonitorMonitor_BizTalk_DiskSpaceStorage_with_Flow.ps1:77 char:1
+ Invoke-WebRequest -Uri ‘https://{URI}.logic.azure.com:44 …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Cause

I had already experienced something similar when communicating with Logic Apps from the BizTalk Server Logic App adapter. However, I had already forgotten about it.

But in fact, the essence of this error and the one I got with the BizTalk adapter is the same.

The Logic App Request trigger supports only Transport Layer Security (TLS) 1.2 for incoming calls. Outgoing calls continue to support TLS 1.0, 1.1, and 1.2.

Solution

The solution was, and is, very simple, we just need to enforce PowerShell to use TLS 1.2. This can be done using this PowerShell one-liner:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
{
$jsonDoc = [pscustomobject]@{
    Monitor = "Disk Space Monitoring"
    Client = "Sandro Pereira"
    Environment = "DEV"
    Disks = $diskNode
}

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -Uri 'https://{URi}.logic.azure.com:443/workflows/{guid}/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig={sig}' -Method POST -Body ($jsonDoc|ConvertTo-Json) -ContentType "application/json"
}

The post Error while calling Logic App thru PowerShell: The underlying connection was closed: An unexpected error occurred on a send. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result.

BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result.

In my infamous crusade to document any BizTalk Server error that I have already come across, here is another error, warnings, cause, and solutions blog post, this time joining another of my favorite topic: Maps.

While trying to deploy a BizTalk Server solution – MSI – into production. While trying to import the BizTalk Application from the .msi file into the BizTalk group by using the BizTalk Server Administration Console by:

  1. Opening the BizTalk Server Administration Console for the instance of BizTalk Server into which you want to import the application. Click Start, click All Programs, click Microsoft BizTalk Server 20xx, and then click BizTalk Server Administration.
  2. In the console tree, expand BizTalk Server Administration, and then expand BizTalk Group.
  3. Right-click Applications, point to Import and then click MSI file.

I came across this error during the progress phase:

Failed to add resource(s). (mscorlib)
– Change requests failed for some resources. (Microsoft.BizTalk.ApplicationDeployment.Engine)
– BizTalkAssemblyResourceManager failed to complete end type change request. (Microsoft.BizTalk.ResourceManagers)
Failed to deploy map “FULLY-QUALIFIED-MAP-NAME”. Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present. (mscorlib)
Error saving map. Stored procedure returned non-zero result. Check if source and target schemas are present. (Microsoft.BizTalk.Deployment)

Error saving map. Stored procedure returned non-zero result

Cause

In previous versions of BizTalk Server, mainly 2010 and 2009, a bug was reported related to this issue. That problem occurred because BizTalk was trying to deploy the mapper assembly before the schema assembly. The solution for that case was installing the cumulative update 4 (or above) for BizTalk Server 2010 or the cumulative update 7 for BizTalk Server 2010.

Nevertheless, I was using BizTalk Server 2016, so that wasn’t the case. Luckily for us, the error provides a piece of clear evidence where the error is happening: FULLY-QUALIFIED-MAP-NAME.

To understand this issue, I went to my dev environment and opened that solution to analyze that specific map, mainly to know which schemas were being used. I then realize that one of the schemas was from an external assembly, a common schema that could be used by several applications.

The cause of this error was precisely that. I used a reference schema (external DLL) inside my map outside the project I was trying to deploy. But that assembly – DLL containing the map’s schema – was not yet deployed in the environment.

Solution

Make sure to deploy all the reference assemblies, special the ones outside your visual studio solution, are deployed before you deploy your solution. And in this case, make sure that all schemas are deployed before installing the maps.

But once again, the critical point here is to make sure to deploy all schemas outside your solution that are being used. Because, even if we use specific projects for maps and schemas inside our solution, BizTalk Server is smart enough to see the dependencies and deploy it accordingly.

After installing the external assembly that contains the schema used by that map, I was able to deploy the BizTalk project into production successfully.

The post BizTalk Solution Deploy Error: Error saving map. Stored procedure returned non-zero result. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk WCF-ORACLEDB Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist

BizTalk WCF-ORACLEDB Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist

Following my previous blog post, Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist, and once I was able to solve that last issue, I was surprised by a brand new communication error between BizTalk Server and ORACLE, fortunately for me, this time with a more explicit error message: ORA-00942: table or view does not exist.

The Messaging Engine failed to add a receive location “ORACLE_RECEIVE_LOCATION_NAME” with URL “oracledb://SERVER_ADDRESS:PORT_NUMBER/SERVICE_NAME/Dedicated?PollingId=polling_id” to the adapter “WCF-Custom”. Reason: “Microsoft.ServiceModel.Channels.Common.MetadataException: Metadata resolution failed for OperationId: “http://Microsoft.LobServices.OracleDB/2007/03/POLLINGSTMT“. —> Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist
   at Oracle.DataAccess.Client.OracleException.HandleErrorHelper(Int32 errCode, OracleConnection conn, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, String procedure, Boolean bCheck, Int32 isRecoverable)
   at Oracle.DataAccess.Client.OracleException.HandleError(Int32 errCode, OracleConnection conn, String procedure, IntPtr opsErrCtx, OpoSqlValCtx* pOpoSqlValCtx, Object src, Boolean bCheck)
   at Oracle.DataAccess.Client.OracleCommand.ExecuteReader(Boolean requery, Boolean fillRequest, CommandBehavior behavior)
   at Oracle.DataAccess.Client.OracleCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.Adapters.OracleCommon.OracleCommonUtils.ExecuteReader(OracleCommonConnectionWrapper connection, String commandText, IEnumerable`1 parameters, CommandBehavior commandBehavior, IOracleAdapterCommonBindingProperties properties, OracleCommonExecutionHelper executionHelper)
   — End of inner exception stack trace —
   at Microsoft.Adapters.OracleDB.OracleCommonMetadataResolverHandler.ResolveOperationMetadata(String operationId, TimeSpan timeout, TypeMetadataCollection& extraTypeMetadataResolved)
   at Microsoft.ServiceModel.Channels.Common.Design.MetadataCache.GetOperationMetadata(String uniqueId, Guid clientId, TimeSpan timeout)
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract..ctor(OracleDBConnection connection, IOracleCommonUDTHelper oracleUdtHelper, MetadataLookup metadataLookup)
   at Microsoft.Adapters.OracleDB.OracleDBConnection.Microsoft.ServiceModel.Channels.Common.IConnection.BuildHandler[TConnectionHandler](MetadataLookup metadataDictionary)
   at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnectionHandler[TConnectionHandler](Guid clientId, TimeSpan timeout, MetadataLookup metadataLookup, String& connectionId)
   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)”.

Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist

Once again, followed by the following error:

The receive location “ORACLE_RECEIVE_LOCATION_NAME” with URL “oracledb://SERVER_ADDRESS:PORT_NUMBER/SERVICE_NAME/Dedicated?PollingId=polling_id” is shutting down. Details:”The Messaging Engine failed while notifying an adapter of its configuration. “.

The Messaging Engine failed while notifying an adapter of its configuration

Of course, these two errors are related, but the first one is the one that has more precise information regarding what is happening.

Cause

As the error message describes, the table or the view you are trial to communicate doesn’t exist on the ORACLE database you are trying to communicate.

Solution

I wish all problems were that simple!

To solve this issue, you need to contact your ORACLE team and make sure that they properly deploy the missing databases, tables, or views.

The post BizTalk WCF-ORACLEDB Oracle.DataAccess.Client.OracleException: ORA-00942: table or view does not exist appeared first on SANDRO PEREIRA BIZTALK BLOG.