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 2020: Hybrid Connectivity with Azure Logic Apps Adapter whitepaper

BizTalk Server 2020: Hybrid Connectivity with Azure Logic Apps Adapter whitepaper

BizTalk Server 2020 is undoubtedly the best-suited integration for the On-Premises integration platform and IaaS (Infrastructure as Service). It is also integrating cloud services with a variety of built-in adapters for the cloud, such as the Azure Logic Apps.

The Azure Logic Apps adapter is used by BizTalk Server to communicate with Azure Logic Apps. This could also be possible using the HTTP adapter, but the Logic App adapter provides a better and straightforward experience.

This whitepaper will show you how BizTalk Server 2020 can interact with Logic Apps:

  • How BizTalk Server can send messages to Logic Apps using the Logic App adapter
  • How Logic Apps can send messages through BizTalk Server using the BizTalk Connector

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:

The post BizTalk Server 2020: Hybrid Connectivity with Azure Logic Apps Adapter whitepaper appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2020: Hybrid Connectivity with Blob Storage Adapter whitepaper

BizTalk Server 2020: Hybrid Connectivity with Blob Storage Adapter whitepaper

We live in the age of fast digital transformation. Different emerging services appear extremely fast which results in a more heterogeneous IT architecture. However, when we have this heterogeneous landscape compose of different legacy and modern systems, a major problem that may arise is how can we put all of these systems to interact with each other to create the concept of a single production system.

BizTalk Server 2020 is undoubtedly the best-suited integration for the On-Premises integration platform and IaaS (Infrastructure as Service). This whitepaper is intended to show you the complete process of receiving and sending messages through the newly introduced Azure Blob Storage adapter.

This whitepaper will give you a detailed understanding of the following:

  • Creating Azure Blob storage
  • Sending messages from BizTalk Server to Blob Storage using the Blob Storage adapter
  • Receiving messages to BizTalk Server from Blob Storage using the Blob Storage adapter

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:

The post BizTalk Server 2020: Hybrid Connectivity with Blob Storage Adapter whitepaper appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server Logic App Adapter: An error occurred while making the HTTP request. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case

BizTalk Server Logic App Adapter: An error occurred while making the HTTP request. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case

I
have an insane roadmap of things to be published but if I didn’t have this week
was fertile in providing me with new content. Full week troubleshooting and
fixing issues in several clients… what an amazing week! But the best one
arrived almost on the last day.

Do
you know the feeling when you develop a solution that has been working properly
for a while and stops working for no logical reason? I bet you do. And this happened
to me this week at a client where we are using the BizTalk Server Logic App
Adapter
to extend part of our logical business to the cloud. And without we
make any changes to the Logic Apps or any changes in our BizTalk Server environment
(aka no new development installed, no patch’s or hotfixes installed, no
restarts, …) everything stops to work, we were not receiving any new messages
on our Logic Apps.

When
I access to BizTalk Server environment, I realize that all the requests were
suspended with the following error:

System.ServiceModel.CommunicationException: An error occurred while making the HTTP request to https://prod-….logic.azure.com/workflows/…/triggers/manual/paths/invoke?queryparameters . This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
  at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)
  at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult a

The adapter failed to transmit message going to send port “LOGICAPP_SEND_PORT” with URL “https://prod-….logic.azure.com/workflows/…/triggers/manual/paths/invoke?queryparameters“. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.ServiceModel.CommunicationException: An error occurred while making the HTTP request to https://prod-….logic.azure.com/workflows/…/triggers/manual/paths/invoke?queryparameters. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server. —> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. —> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. —> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host

   at System.Net.Sockets.Socket.EndReceive(IAsyncResult asyncResult)

   at System.Net.Sockets.NetworkStream.EndRead(IAsyncResult asyncResult)

   — End of inner exception stack trace —

   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)

   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)

   — End of inner exception stack trace —

   at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)

   at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)

   — 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)”.

Logic App Adapter: This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server

The other curious thing was that all my environments DEV, QA, and PROD were with the same symptom and all of them start at the same time which made this problem even more intriguing.

However,
I was able to connect with the adapter, see and select all the Logic Apps in my
subscription.

Logic App Adapter configuration on the BizTalk Server administration Console
Logic App Adapter configuration on the BizTalk Server administration Console

To
demystify if that was a problem with the adapter, I switch to the HTTP adapter
in order to try. Nevertheless, I got identical problems that made me dismiss
the idea that there could be something wrong with the adapter.

The
next step was to see if there was a network issue, maybe a firewall or proxy, which
should be because there was no intervention in the environment, but it is
always worth testing. To do that, I used one of my favorite tools, postman, and
to my surprise, everything was working fine. I was able to communicate and send
requests to all my Logic Apps in all my environments!

Cause

If you don’t are really
familiar with this type of problem, you may be pointed for a certificate issue,
but in our case, we were not using any kind of certificates to call our Logic
Apps and no additional type of authentication.

But I was sure that I had
already seen that error in the past, and I was related to security protocol (TLS
1.0 or TLS 1.2) used on the HTTPS communication and yes HTTPS because
all Logic Apps endpoints are in HTTPS.

BizTalk
Server came out-of-the-box and works very well with SSL (Secure Socket Layer)
3.0 or TLS (Transport Layer Security) 1.0, and these are the security
protocol used. New versions of BizTalk Server allow us to use TLS 1.2, but that
required extra manual configurations that we need to do in the environment and I
know that everyone is deprecating TLS 1.0 and 1.1 because of the well know vulnerabilities,
nevertheless, everything was working fine I have been doing this kind of hybrid
solution connecting with Logic Apps.

What
I discovered on the official documentation was that they say that: The
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.

Nevertheless,
that wasn’t true until a few days ago, and my guess is that they actually discontinue
support for TLS 1.0 and 1.1 on the incoming calls without any notice, something
that, in my opinion, you shouldn’t do.

Solution

The solution was very simple,
we just need to specify that the default security protocol on BizTalk Server is
TLS 1.2. And to do that you need:

  • To
    make some changes on the registry to set TLS 1.2 as default security protocol TLS1.2;
  • Or
    creating a Custom BizTalk Server behavior;

I
choose the first option, making some changes to the registry. And to accomplish
that we need to add the below DWORD values in our registry:

  • On the [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Client]
    • Create the following DWORD (32-bit) values
      • Name: DisabledByDefault
        • Value Data: 0
      • Name: Enabled
        • Value Data: 1
  • On the [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.2Server]
    • Create the following DWORD (32-bit) values
      • Name: DisabledByDefault
        • Value Data: 0
      • Name: Enabled
        • Value Data: 1
  • On the [HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
    • Create the following DWORD (32-bit) values
      • Name: SchUseStrongCrypto
        • Value Data: 1
  • On the [HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]
    • Create the following DWORD (32-bit) value
      • Name: SchUseStrongCrypto
        • Value Data: 1

If
you try resending a message to your Logic App, everything should work properly
again.

The post BizTalk Server Logic App Adapter: An error occurred while making the HTTP request. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case appeared first on SANDRO PEREIRA BIZTALK BLOG.

BizTalk Server 2016: step by step Logic App adapter installation guide

BizTalk Server 2016: step by step Logic App adapter installation guide

My latest BizTalk Server whitepaper has been published: “BizTalk Server 2016: step by step Logic App adapter installation guide” and I’m thrilled!

BizTalk Server 2016: step by step Logic App adapter installation guide

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:

The post BizTalk Server 2016: step by step Logic App adapter installation guide appeared first on SANDRO PEREIRA BIZTALK BLOG.

Migrating BizTalk to Azure iPaaS – Part 1

Migrating BizTalk to Azure iPaaS – Part 1

By Bill Chesnut

This is the 1st of a multipart series of Blog Posts to help companies understand Migrating BizTalk to Azure Integration Platform as a Service (IPaaS).

Should I be migrating from BizTalk to Azure iPaaS? This is a question I am being ask more and more lately for a couple of different reasons.

BizTalk development has always been a very specialized skill set with a limited number of resources available in the market, so companies are now starting to look at Azure iPaaS as a viable alternative to BizTalk in terms of finding developers with the correct skill sets.

There are 3 other reasons many companies are looking at moving from BizTalk to Azure iPaaS:

  • cost, consumption pricing instead of product licensing;
  • location of data, many companies are dealing with their consumers over the internet, so having their integration resources in Azure makes more sense;
  • Infrastructure, companies are seeing the advantages of not having to maintain their own infrastructure and using Platform as a Service (PaaS) and Software as a Service (SaaS) offerings as a cost-effective alternative.

Unlike the BizTalk middleware products that covered most features required for all integration scenarios, Azure iPaaS is a collection of Azure services that may or may not be utilised for each scenario.

The base components that make up Azure iPaaS are Service Bus, Logic Apps, API Management and Event Grid. For some integration scenarios you may also use services like but not limited to: SQL Database, Storage, Function App, Web Site (hosing your WebAPI or WebJobs), Cosmos Db and Virtual Machines.  In this series of blog posts, I will look at the different scenarios and the Azure services required.

Instead of spending time here to explain each of the Azure iPaaS services, I have included links to Azure documentation on each product/service mentioned:

All Azure Product/Services can be found here: https://docs.microsoft.com/en-us/azure/#pivot=products

Before you jump full steam into migrating from your on-premises (or cloud hosted) BizTalk to Azure iPaaS, there are a few things that you need to look at to see if the migration makes sense:

  • Location of your data
  • Sensitivity of your data
  • Security Policies for accessing cloud-based resources
  • Location of consumers/partners

Let’s look at each of these items in detail:

Location of your data, if most of your data currently used by BizTalk is located inside of your data center it would be hard to justify moving all of that data to and from Azure to use Azure iPaaS.

If your data is from your consumers/partners and it is coming in and going out via the internet, iPaaS can be a great solution in terms of cost, scalability and availability.

Sensitivity of your data, again this will relate back to the first item, if the data is coming in and going out over the internet, your company has already accepted the risk, so iPaaS will be a viable solution, otherwise, a risk assessment will need to be undertaken.

Security Policies for accessing cloud based resources can sometimes be one of the hardest nuts to crack, it requires educating your management to the benefits and security safe guards of Azure. It also means designing your iPaaS solution to use some of the additional security features available in Azure.  The final point to look at is location of consumers/partners, again if everyone using the integration service of BizTalk are located inside of your data center, having them traverse to Azure and back for data does not make sense, but if many of your consumers/partners are outside of your offices or mobile users, Azure make perfect sense for availability and scale.

Once a company has decided that moving to Azure iPaaS makes sense, the next item to consider is the structure of their existing BizTalk integration solution, does the existing BizTalk solutions follow best practice:

  • having incoming data mapped to an internal/canonical format
  • processed in BizTalk using the internal/canonical format
  • then mapped back to the outbound format before leaving BizTalk

if so, this will make the migration to Azure iPaaS a less disruptive and staged process.

This series will continue with the following blog posts:

  • Migrating inbound messaging to Azure using Logic Apps, Event Grid, Service Bus and the BizTalk Claim Check Pipeline component that I have built.
  • Migrating outbound messaging to Azure, using the same tooling as inbound
  • Choices for message archiving in Azure
  • End to End Monitoring of Azure iPaaS
  • EDI (EDIFACT, X12 & AS2) Capabilities of Azure iPaaS
  • Azure iPaaS CI/CD

Thanks for taking the time to view this blog post.

Cross Posted on: http://www.sixpivot.com.au

Microsoft Integration Weekly Update: July 2, 2018

Microsoft Integration Weekly Update: July 2, 2018

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

If you want to receive these updates weekly, then don’t forget to Subscribe!

 

Feedback

Hope this would be helpful. Please feel free to reach out to me with your feedback and questions.

Advertisements

When to use Logic Apps vs BizTalk Server

When to use Logic Apps vs BizTalk Server

Now a days, this is a very common and valid question in the BizTalk community, both for existing BizTalk customer and for new one too.

Here is what Tord answered in the open Q&A with product group at 100th Episode of integration Monday.  Check at ~ 30.30 minutes of the video.

If your solution need to communicate with SaaS application, Azure workloads and cloud business partners (B2B) all in cloud then you should use Azure Logic Apps, but if you are doing lot of integration with on-premise processing by communicating with on-premise LOB applications, then BizTalk is the pretty good option. You can use both if you are doing hybrid integration.

So basically, it depends on scenario to scenario based on your need and architecture of your solution.

Many enterprises now use a multitude of cloud-based SaaS services, and being able to integrate these services and resources can become complex. This is where the native capability of Logic Apps can help by providing connectors for most enterprise and social services and to orchestrate the business process flows graphically.

If your resources are all based in the cloud, then Logic Apps is a definite candidate to use as an integration engine.

Natively, Logic Apps provides the following key features:

Rapid development: Using the visual designer with drag and drop connectors, you design your workflows without any coding using a top-down design flow. To get started, Microsoft has many templates available in the marketplace that can be used as is, or modified to suit your requirements. There are templates available for Enterprise SaaS services, common integration patterns, Message routing, DevOps, and social media services.

Auditing: Logic Apps have built-in auditing of all management operations. Date and time when workflow process was triggered and the duration of the process. Use the trigger history of a Logic App to determine the activity status:

  • Skipped: Nothing new was found to initiate the process
  • Succeeded: The workflow process was initiated in response to data  being available
  • Failed: An error occurred due to misconfiguration of the connector

A run history is also available for every trigger event. From this information, you can determine if the workflow process succeeded, failed, cancelled, or is still running.

Role-based access control (RBAC): Using RBAC in the Azure portal, specific components of the workflow can be locked down to specific users. Custom RBAC roles are also possible if none of the built-in roles fulfills your requirements.

Microsoft managed connectors: There are several connectors available from the Azure Marketplace for both enterprise and social services, and the list is continuously growing. The development community also contributes to this growing list of available connectors as well.

Serverless scaling: Automatic and built in on any tier.

Resiliency: Logic Apps are built on top of Azure’s infrastructure, which provides a high degree of resiliency and disaster recovery.

Security: This supports OAuth2, Azure Active Directory, Cert auth and Basic auth, and IP restriction.

There are also some concerns while working with Logic Apps, shared by Microsoft IT team at INTEGRATE 2017

You can also refer the book, Robust cloud integration with Azure to understand and get started with integration in cloud.

 

When you have, resources scattered in the cloud and on premise, then you may want to consider BizTalk as a choice for this type of hybrid integration along with Logic Apps.

BizTalk 2016 include an adapter for Logic Apps. This Logic App adapter will be used to integrate Logic Apps and BizTalk sitting on premise. Using the BizTalk 2016 Logic App adapter on-premise, resources can directly talk to a multitude of SaaS platforms available on cloud.

The days of building monolithic applications are slowly diminishing as more enterprises see the value of consuming SaaS as an alternative to investing large amounts of capex to buy Commercial Off the Self (COTS) applications. This is where Logic Apps can play a large part by integrating multiple SaaS solutions together to form a complete solution.

BizTalk Server has been around since 2000, and there have been several new products releases since then. It is a very mature platform with excellent enterprise integration capabilities.

Below is a short comparison matrix between BizTalk and Logic Apps:

Conclusion

Microsoft Integration platform has all the option for all kind of customer’s integration need.

Advertisements

Microsoft Integration Weekly Update: April 10

Microsoft Integration Weekly Update: April 10

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

If you want to receive these updates weekly, then don’t forget to Subscribe!

On-Premise Integration:

Cloud and Hybrid Integration:

Feedback

Hope this would be helpful. Please feel free to let me know your feedback on the Integration weekly series.

Advertisements

Microsoft Integration Weekly Update: April 10

Microsoft Integration Weekly Update: April 10

Do you feel difficult to keep up to date on all the frequent updates and announcements in the Microsoft Integration platform?

Integration weekly update can be your solution. It’s a weekly update on the topics related to Integration – enterprise integration, robust & scalable messaging capabilities and Citizen Integration capabilities empowered by Microsoft platform to deliver value to the business.

If you want to receive these updates weekly, then don’t forget to Subscribe!

On-Premise Integration:

Cloud and Hybrid Integration:

Feedback

Hope this would be helpful. Please feel free to let me know your feedback on the Integration weekly series.

Advertisements