Host Integration Server 2016: Invalid Assembly. Assembly does not contain any TI Objects that inherit from interface

Host Integration Server 2016: Invalid Assembly. Assembly does not contain any TI Objects that inherit from interface

While going through my adventure on a BizTalk Server + Host Integration Server (HIS) project and mainframe connectivity, I’m trying to migrate an old HIS2006 solution to BTS2016 + HIS2016. Just ten years of evolution, I notice that:

  • Many things on HIS2006 are not compatible with HIS2016.
    • You may found some new limitations and new features.
    • Luckily Microsoft provides tools to migrate several components, especially the TI resources.
  • HIS Tools have changed:
    • SNA Manager is quite the same. Maybe some screens and options are a bit different.
    • TI Manager is no longer available. Now we have a different tool called TI Configuration Tool with the same goals as the previous one. However, the way we configure Host-Initiated Processing (HIP) and Windows-Initiated Processing (WIP) is different nowadays.
  • The HIS documentation is quite limited, and you will not find much information about it.

I have to say I’m lucky to have good friends, and because of that, I have been learning a lot with my dear friend Steve Melan, that is the best expert I know regarding HIS.

The last strange (all of them are strange) issue I encountered while trying to Add Host-Initiated Processing (HIP) Object on my HIP configuration by using the Transaction Integration (TI) Configuration Tool was:

Add TI HIP Implementing Assembly

Invalid Assembly. Assembly does not contain any TI Objects that inherit from interface: namespace.interface

Or in other cases:

Invalid Assembly. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Cause

As I told you before, many things changed from HIS2006 to HIS2016, and migrate the Host Application projects is not direct – Visual Studio does not migrate the project as it does for a C# project or BizTalk Server project. Instead, you need to migrate the resources using the TIConversionTool and then import them to your Visual Studio Host Application project.

And you need to make sure that you are not breaking anything like methods and interface names. And then, you need to reference these new resources (DLL containing the .Net Server Definition) on your interface implementation project. This interface implementation is a C#, or VB, class library project. Then, inside that project, you need to create a class that implements the inherited .Net Server Definition interface and provides the implementation of all the members defined within the interface – in this case, all the operations or COBOL programs in that Host Application .Net Server Definition.

My problem was that this interface implementation was also a very old project, compiled in .NET 2.0. For some reason, I yet not completely understood, and despite successfully migrating them to .NET4.6.1, I couldn’t make it fully compatible with the HIP, and I always got these two issues above.

Solution

The resolution was, in fact, quite simple. Basically, I create a new C# class library project from scratch and copy-paste all the existing code to the new one, recreating the old one manually.

Surprise… everything work perfectly! And then, I could create the HIP object.

An example of a Host Application .Net Server Definition interface implementation is something like this:

using RemoteOrder;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
using System.Text;
using System.Threading.Tasks;
using IHIPServices;

namespace TestOrders
{
    public class OrderImplementation : IHIPServices
    {
        void IHIPServices.GetOrders(ref string value)
        {
            /*
             * Implement the logic
             * 
            */
        }
    }
}

What you need to be aware of are:

  • It should reference these two HIS assemblies:
    • Microsoft.HostIntegration.TI.ClientContext
    • Microsoft.HostIntegration.TI.ServerContext
  • It should reference the Host Application .Net Server Definition assembly
    • In this case, represented by IHIPServices
  • Implement the interface members
    • In this case, represented by IHIPServices.GetOrders(ref string value)

The post Host Integration Server 2016: Invalid Assembly. Assembly does not contain any TI Objects that inherit from interface appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information

BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information

In the last blog post of this series I address a “strange” behavior – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience – about Sign-in to Azure doesn’t respond.

Today we are going to address a new one, make note that all of them will be related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page.

Incorrect Sign-In account information

In the first blog post, we address the behavior of No user is logged in. Although the lack of this information is not critical to the send port’s correct functioning, I mention that it would be helpful for those who manage the platform to have this information available. 

In this case, let’s assume that after a while (one week or one month later), we go to that send port, and what we see is No user is logged in…

Or even we create the port, and there is an account defined there, let’s say my email account.

If we click on Sign-in to Azure once again, no matter if there is an account display there or not. This will pop up a Log in to your account window and let’s assume:

  • Initial we had authenticate using my account: [email protected]
  • but now we are going to select a different account

Note: sorry for the picture to be in Portuguese ?

After we select the account the password will be asked. You type the password and click begin log in (begin session) and for some reason, a screen asking additional information will be showed to define phone number, email, and security questions.

If you don’t want to define this information, or you are not responsible to perform this configuration and decide to abort this process by click Cancel.

Once you get back to the Logic App Details Page on the BizTalk Server Administration Console the account you try to define to authenticate on Azure to define this port will sow the user you define on the process you just aborted. Despite being strange is not incorrect because in fact, you did authentic on Azure and you are able to see different subscription:

  • The Resource, Logic App and Trigger are gray because the user I used doesn’t have access to that subscription but instead to a different one

Now, if I say: upps!! I made a mistake. Let’s cancel this process and click three times on the cancel button to be sure I discard any change I did. Once we go again to the configuration of that port, what we will see is precisely the previous account being display there!

Again, this is not entirely wrong. What is displaying there is the last user you used to authenticate on Azure… but it is not correct in terms of user experience and it may induce BizTalk Server Administration in error. It was not that user that we used to define the configuration of that port, and neither this account has access to that subscription!

In my opinion, the last user account that successfully defined or made chances on the port should always be displayed.

And the only way to not see that information on that port is to close the Administration Console and open it again. After that at least you will see No user is logged in. This is also not an ideal situation, and it could mislead administrators once again.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #3 Incorrect Sign-In account information appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond

BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond

On the first blog post of this series I address a “strange” behavior – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience – about No user is logged in.

Today we are going to address a new one, make note that all of them will be related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page

Sign-in to Azure doesn’t respond

I work a lot with several clients in Portugal and outside Portugal. If it was already expected before this COVID-19 pandemic, it is now almost mandatory to work with several VPNs tools and configurations to access their environments.

Some of these VPN configurations allow me to continue to have internet access on my laptop. Others have this annoying behavior to cut access to the internet. In the current world situation with homework that we are, or need to be, online to speak with the team and clients, having no internet access because of a VPN is not a good situation. To avoid this situation or have a better experience, aka not stay offline, I usually install these VPN tools on my Virtual Machines. By doing this strategy, my laptop stays with internet access, but my VM doesn’t have. And it was in one of these situations I found this “strange” behavior.

When I access my Logic App Send Port configuration details on BizTalk Server Administration Console, I try to click several times on the Sign-in to Azure button:

But to my surprise, without any response or action to be presented. It seems that the button was not responding. Sometimes, after a few minutes, a blank pop-up window appears, but it disappears after a minute or so. And this without presenting any error or warning message!

I then realized that I was connected to a VPN, and my machine was without internet access:

Of course, when I turned off the VPN and my VM had access to the internet again, everything started to work as expected.

This is simply a bad user experience implementation. It should at least pop up a warning message that couldn’t connect with Azure or to the internet.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #2 Sign-in to Azure doesn’t respond appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in

BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in

After working with BizTalk Server Logic App Adapter for a while, I saw some configurations “strange” behaviors – maybe strange is not the best work. They are not issues, but definitely, they could have a better user experience.

All of them are related to the Logic App Adapter Azure Authentication (Sign-in to Azure) that you can find on the Endpoint Address Configuration Logic App Details Page

No user is logged in

Once you configure the Logic App port, in this case, a send port, you need to sign in to Azure. This will pop up a window where you need to enter your account and password (Multi-factor Microsoft Authenticator). After that, you will see an identical configuration to what is shown in the picture below:

  • Account
  • Subscription
  • Resource Group
  • Logic App
  • and Trigger

If you then finish the configuration of the port, everything will be ok, and if you return later to the configurations onto that same send port, you will still be able to see that the account that I used to authenticate was my personal account:

However, if you close the BizTalk Server Administration Console, once you open again and access the configuration of that send port, you still be able to see the following information:

  • Subscription
  • Resource Group
  • Logic App
  • and Trigger

But you no longer be able to identify what account that was used to authenticate on Azure.

Although the lack of this information is not critical, I think it would be helpful for those who manage the platform to have this information available.

The post BizTalk Server Logic App Adapter Configurations strange behaviors – #1 No user is logged in appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020 Logic App Receive Adapter: The error occurred because the component does not implement the mandatory interface “IBTTransportControl”.

BizTalk Server 2020 Logic App Receive Adapter: The error occurred because the component does not implement the mandatory interface “IBTTransportControl”.

A few months ago, I was playing around with BizTalk Server hybrid Integration, in this case, trying to send messages from Logic App to BizTalk Server by using the Send message action of the Logic app BizTalk Server connector. While I conducted the first set of tests, I realized my Logic App was failing to send the message to BizTalk Server. On the BizTalk Server machine, I found that BizTalk Server was throwing the following error while receiving the message:

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. “.

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. “.

WebHost failed to process a request.

 Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/63835064

 Exception: System.ServiceModel.ServiceActivationException: The service ‘/LogicAppTestService/Service1.svc’ cannot be activated due to an exception during compilation.  The exception message is: Receive location for address “/LogicAppTestService/Service1.svc” not found. (The BizTalk receive location may be disabled.). —> Microsoft.BizTalk.Adapter.Wcf.AdapterException: Receive location for address “/LogicAppTestService/Service1.svc” not found. (The BizTalk receive location may be disabled.)

   at Microsoft.BizTalk.Adapter.Wcf.Runtime.ReceiveLocationManager`2.GetEndpointContext(Uri uri)

   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WebServiceHostFactory`3.CreateServiceHost(String constructorString, Uri[] baseAddresses)

   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.CreateService(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)

   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity)

   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)

   — End of inner exception stack trace —

   at System.ServiceModel.ServiceHostingEnvironment.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity)

   at System.ServiceModel.ServiceHostingEnvironment.EnsureServiceAvailableFast(String relativeVirtualPath, EventTraceActivity eventTraceActivity)

 Process Name: w3wp

 Process ID: 8068

I faced similar issues in the past with other adapters (HTTP, WCF, SOAP, …). However, I knew that I had published the service on IIS with the correct App Pool, privileges and the BizTalk Server receive port associated with this server was running (Enabled).

Nevertheless, my first action was to validate the I could access that URL on the browser, and to my surprise, it was failing!

Luckily I found a very good post written by my friend Ahmed Taha explaining the reason why that was happening and the solution

Cause

The reason for this issue is a bug on the default BizTalk Server 2020 configuration tool that assigns the Logic App Receive Adapter to an In-Process host. The correct setting is to be bound to the Isolated host.

Solution

The resolution is simple but a little annoying.

  • First, you need to remove the adapter from all assigned send ports and receive locations from all your BizTalk Server applications.
    • YYou can optimize this process using PowerShell, or if you were lucky like me that only have one receive port and one send port, you could easily do that manually..

Note: These scripts were taken from the Microsoft BizTalk Server Adapter for Logic Apps installer used for BizTalk Server 2016.

These steps resolved the Logic App Adapter Handler Receive configuration issue in BizTalk Server 2020 and correctly bound it to the Isolated host. So if you try now to configure your receive port, it should work fine.

Final note: BizTalk Server Cumulative Update 2 already provide a hotfix to this issue:

5003146 FIX: Unable to receive messages using LogicApp adapter because the receive location is getting disabled

After applying this fix, new receive handlers will be added as Isolated receive handler. However, any existing in-process LogicApp receive handlers need to be deleted manually. So basically, you need to reconfigure all your Receive Locations to use the Isolated host and then delete the receive handlers bounded to the In-Process host.

The post BizTalk Server 2020 Logic App Receive Adapter: The error occurred because the component does not implement the mandatory interface “IBTTransportControl”. appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2016: “Empty BizTalk Server Project” Template missing from Visual Studio 2015

BizTalk Server 2016: “Empty BizTalk Server Project” Template missing from Visual Studio 2015

A few days ago, I wrote a blog post about a similar topic, but in that case, it was the BizTalk Server Application Project Visual Studio that was missing. In fact, at that point, the Empty BizTalk Server Project Visual Studio template was also missing in the development environment.

It is not a common situation in a BizTalk Server Development environment, but I cannot say that this is the first time I have found this issue.

I tried to see if the project template was available on the local system. Normally VS stores the available templates at Program Files(x86) -> Microsoft Visual Studio 14.0 -> Common7 -> IDE -> ProjectTemplates, but the template was there:

Cause

I don’t know very precisely why Visual Studio was not loading the most critical BizTalk Server Visual Studio template, and it is hard to find the proper cause of this issue.

Of course, this problem was not related to the lack of installation of the development tools and the SDK. The Developer tools and SDK component was installed during the BizTalk Server installation.

On a quick search over this issue, I found several mentions that you could solve this issue by installing the template available on the Visual Studio Marketplace. According to the documentation, this template is available for Visual Studio 2015, 2017 (?), and 2019.

  • Note: I don’t know any version of BizTalk Server that works on Visual Studio 2017

However, trying to install this template using the marketplace, I got a dependency alert for Visual Studio MPF 16.0. I try to follow the instructions provide by Microsoft to overcome this problem in which you can get more information here, but without any practical effect.

So, I went applying the traditional method to solve the problem of the missing template.

Solution

To fix this issue, the solution is quite simple:

  • You need to Repair the Visual Studio installation
  • After you repair the Empty BizTalk Server Project will be available

The post BizTalk Server 2016: “Empty BizTalk Server Project” Template missing from Visual Studio 2015 appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk WCF-OracleDB Error: Microsoft.ServiceModel.Channels.Common.ConnectionException —> Oracle.DataAccess.Client.OracleException

BizTalk WCF-OracleDB Error: Microsoft.ServiceModel.Channels.Common.ConnectionException —> Oracle.DataAccess.Client.OracleException

Yesterday I was troubleshooting a WCF-OracleDB issue on BizTalk Server 2016, and I got surprised, or not, by the lack of information that I was receiving about the problem that was happening. We usually get some minor help from the adapter that throws a short error message description like:

  • table or view does not exist
  • The provider is not compatible with the version of Oracle client
  • This is because either (a) ambient transaction is present and the TNS alias is longer than 39 characters
  • PL/SQL: ORA-00917: missing comma
  • Could not load file or assembly ‘Oracle.DataAccess, Version=2.111.7.0, Culture=neutral, PublicKeyToken=89b483f429c47342’ or one of its dependencies. The system cannot find the file specified.

and these are just a few examples that you can find in my blog. Nevertheless, this time, I was getting a simple:

The Messaging Engine failed to add a receive location “TEST” with URL “oracledb://ServerAddress:PortNumber/ServiceName/ServiceType” to the adapter “WCF-OracleDB”. Reason: “Microsoft.ServiceModel.Channels.Common.ConnectionException —> Oracle.DataAccess.Client.OracleException
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, IntPtr opsErrCtx, Object src)
at Oracle.DataAccess.Client.OracleConnection.Open()
at Microsoft.Adapters.OracleCommon.OracleCommonConnectionWrapper..ctor(String connectionString, OracleCommonExecutionHelper executionHelper)
at Microsoft.Adapters.OracleDB.OracleDBConnection.Microsoft.ServiceModel.Channels.Common.IConnection.Open(TimeSpan timeout)
— End of inner exception stack trace —
at Microsoft.Adapters.OracleDB.OracleDBConnection.Microsoft.ServiceModel.Channels.Common.IConnection.Open(TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnection(Guid clientId, TimeSpan timeout)
at Microsoft.ServiceModel.Channels.Common.Design.ConnectionPool.GetConnectionHandler[TConnectionHandler](Guid clientId, TimeSpan timeout, MetadataLookup metadataLookup, String& connectionId)
at Microsoft.ServiceModel.Channels.Common.Channels.AdapterChannelListener1.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.WcfReceiver2.AddReceiveEndpoint(String url, IPropertyBag adapterConfig, IPropertyBag bizTalkConfig)”.

Cause

Diagnose a problem is typically not an easy task. That becomes even harder if no error details are provided. Nevertheless, if you face this issue, my experience tells that some ORACLE required components are missing on your BizTalk Server environment.

This was the conclusion I got with the help of good ORACLE expert friends that are working with me on the project.

Solution

The solution is to install all the ORACLE necessary components based on Microsoft documentation: the Oracle Data Access Components (ODAC) 32 and 64 bits.

The easier way for you to solve this issue is by simply use Oracle client resources. In my case, I tend to use: Oracle 12C client 32 bit and Oracle 12C 64-bit Client:

  • Double-click on setup.exe
  • On the Select Installation Type page, select the Runtime option
    • This will probably install more components that you need but at least will install all the necessary components
  • On the Select Product Languages page, leave the default language. English, and click Next.
  • On the Specify Oracle Home User page, select the option Use Windows Buit-in Account, and click Next.
  • On the Specify Installation Folder screen, review the installation paths and click Next.
  • On the Perform Prerequisites Checks screen, wait for the wizard finish doing the checks necessary and it will automatically jump to the Summary page.
  • On the Summary screen, review the summary and click Install.

After that, I was able to successfully communicate with the Oracle database.

The post BizTalk WCF-OracleDB Error: Microsoft.ServiceModel.Channels.Common.ConnectionException —> Oracle.DataAccess.Client.OracleException appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2016: “BizTalk Server Application Project” Template missing from Visual Studio 2015

BizTalk Server 2016: “BizTalk Server Application Project” Template missing from Visual Studio 2015

Today, I encountered a “strange behavior” on one of my BizTalk Server 2016 clients. When I opened Visual Studio to create a new BizTalk Server project, I realized that the “BizTalk Server Application Project” template was missing from the available list. Instead, I could only find “BizTalk Server BPEL Import Project”. This was the first time I encountered this behavior/issue.

That was a bit strange. I already had in the past situations where none of the Visual Studio BizTalk templates were present. So basically, we need or repair Visual Studio or repair BizTalk Server installation to solve the issue.

Cause

All Visual Studio BizTalk Server 2016 projects need to be compiled on .NET Framework 4.6.1 (minimum and by default) or .NET Framework 4.7.x (Starting with CU2) and .NET Framework 4.8 (Starting with CU7).

That means that the Visual Studio BizTalk Server Application Project template is only available if you select the .NET Framework 4.6.1 or above. In my case, the template was not missing. It wasn’t showing because, for any reason, I could find the selected .NET Framework when I opened VS was 4.5.2.

Solution

To fix this issue, the solution is quite simple:

  • On the New Project window, on the .NET framework combo box present in the top of the windows, select the option .NET Framework 4.6.1
  • And the project template will be available for you to use.

The post BizTalk Server 2016: “BizTalk Server Application Project” Template missing from Visual Studio 2015 appeared first on SANDRO PEREIRA BIZTALK BLOG.