Stephen W. Thomas shares his view on how BizTalk Server can be used as a foundation to using the cloud. He explains why you could use BizTalk Server combined with Logic Apps and addresses how to deal with the friction factors related to this.
Integrate 2018, June 4-6, etc.venues, London
Stephen: For starters, my name is Stephen W. Thomas, for those of you that don’t know me. Thank you, and today’s session is on using BizTalk Server as your foundation to the clouds. When I got this session accepted I saw where I was going to be in the lineup today I figured this has to be one of the best session spots right before the attendee party. So, you know, whether or not you like my session or not, about an hour from now everyone will be listening to live music and having a drink and everyone will be happy. So hopefully, you do like my session.
So about two months ago I presented at the Global Azure Boot Camp in Austin, Texas. It was the first time I’ve ever talked in the same city I live in, which was kind of interesting, waking up in my own bed and going and presenting. But and that session I followed a Microsoft Azure solution architect who gave a really nice presentation on blockchain and after his presentation quite literally 1/5 of the room rushed the stage. There were people with microphones and recorders wanting to get comments from him. It was unlike anything I’d seen.
So then I went up and I gave my presentation and I’ll leave it up to your imagination on what happened at the end of that one. There was one person using BizTalk Server in the room, so we had that. I’ll give you a little bit of history about me for those of you that haven’t seen me before. I’ve been doing consulting for almost 20 years now. I’ve been working with BizTalk Server since 2001. I actually started with the first version of BizTalk in BizTalk 2000. I’ve been working with Logic Apps for over two years now. I’m a 13-year Microsoft MVP.
I used to be in BizTalk Server, now we’re in Azure. Anybody has any comments or questions feel free to reach out to me anytime at email@example.com, hopefully that’s easy to remember, and feel free to follow me on Twitter as well if you’d like. I want to point out a few learning paths for Logic Apps for anybody that wants to learn a little bit more about a lot of the stuff we’ve seen for the last couple of days.
First off, there’s two Pluralsight courses out there. I worked on both of those. I have a getting started course, which is about an hour-and-a-half long, and then I have a fundamentals course, which is about three hours long. The fundamentals course goes through step by step a lot of the concepts that we’ve seen here in demos such as creating custom API connections and creating in-order message delivery modules on all that. Also, remember you can watch your Pluralsight courses at one-and-a-half speed so you can get through them a lot quicker that way. You can’t listen to me right now at one-and-a-half speed, unfortunately.
If anybody doesn’t have access to PluralSight, I have some free 30-day trial codes. Just shoot me an email, there’s no credit card required with the trial codes that I have so you can play around with that. I’ve been doing some instructor-led training with a company called QuickLearn. They’re very well known for their BizTalk courses. They also have a weeklong, instructor-led course on cloud-based integration using Azure Logic Apps. It’s a really good course, walks you through end to end, your Logic App solutions.
We even take a look at creating custom triggers for your Logic Apps using API Apps. So that was something I didn’t even know you could do until I started teaching the course. Is there anybody in here that’s not created a Logic App? Okay, so almost nobody. That’s fantastic. If anybody wants more experience I do have some hands-on labs so it walks you through it beginning to end. They’re about 23 pages long, real detailed. Just go to my website/labs and you can get some more experience with Logic Apps.
Let me talk a little bit about how I’m going to lay out this session. First off, I have phase one, which is we’re going to talk about why you’d want to use BizTalk and Logic Apps together in the first place. Is there anybody here that’s using BizTalk and Logic Apps together today? Oh, fantastic. Phase two, we’re going to talk about some friction factors that might prevent you in your company for using BizTalk and Logic Apps. Anybody running into friction using BizTalk and Logic Apps or thinks they should be using it? Okay, a couple. So hopefully, we’ll take a look at some common roadblocks I’ve seen clients run into and kind of some ways to help get past those roadblocks.
So phase one, why BizTalk and Logic Apps? So first off, I’ll be the first one to say that it doesn’t make sense in all scenarios. If you’re 100% on-premise with your BizTalk environment trying to bring in Logic Apps it might not make sense. If you’re in a low latency scenario where you need to have a second, sub-millisecond execution it might not make sense. And also if you have no plans to ever do anything, no paths services outside of your data center it also doesn’t make sense to probably look at this.
So let’s look at the reasons why it does make sense. The most common is for leveraging connectors that aren’t available on BizTalk out-of-the-box. You know, BizTalk has about 35 different adapters, mostly around on-premise integration. We know that Logic Apps has over 200. Again, they’re kind of more focused on paths integration. So they kind of solving different spaces but with Logic Apps and BizTalk, you get access to all those connectors.
We can help reduce the load on our current BizTalk Servers. So maybe we have some de-batching scenarios, we have some large flat file scenarios where we’re putting a burden on our BizTalk environment to start running as well as it could. We could look at moving some of that up into Logic Apps to get our BizTalk Server to run better. Also, planning for the future. If you don’t use any [inaudible 00:05:51] offerings today chances are five years from now there will be some in the mix. If you get started with Logic Apps now then it’s going to be easier to integrate those systems later in the future.
Also, it might be possible to save on hardware and software costs. So a lot of clients are upgrading from BizTalk 2010 and ’13 to BizTalk 2016. With that comes new hardware. It might make sense to look at some workloads that you might be able to offload to Logic Apps in order to reduce the size of your on-premise BizTalk environment. And last is about becoming an integration hero at your clients. If you help bring in change, help introduce Logic Apps, help getting custom to change now sooner rather than later, you can achieve what we saw yesterday from our integration hero perspective.
How can we do that? We have so many different options now. The most popular one, the one I like the best is integration via Service Bus queues. So we would write data from our BizTalk environment to Service Bus and pick that up in our Logic Apps and then Logic Apps send it back to Service Bus to our on-prem BizTalk Server. This just seems to be a nice, reliable way to transmit data back and forth. We also have the built-in Logic Apps adapter inside the BizTalk Server. So we’re able to call HTTP-exposed endpoints directly from BizTalk.
We have the on-premise data gateway, which is a little more designed for Logic Apps calling in to on-premise, but that’s there for us to leverage as well. We have good old-fashioned API calls. We can use the API calls to talk back and forth, combine that with the relay service to expose your internal calls externally, securely through the relay service. And then we have ISE with VLAN, which is something kind of new that we just learned about this morning.
So now, I’m going to walk through a series of six different scenarios that I’ve kind of outlined where it makes a lot of sense to try to think about BizTalk and Logic Apps working together to solve your integration needs. First off, is [inaudible 00:07:51] connectors that are external to BizTalk. One of the most common ones I see clients go with is monitoring social media. A lot of times this is used in conjunction with cognitive services.
Now, I’ll be the first one to admit that three years ago when I saw Logic App demos with Twitter I was very skeptical. To me, that didn’t necessarily seem like an enterprise use but now every single client I’m at has either a full team or an outsourced team of resources that just monitor their social media brand. Not only are they monitoring the brand, they’re monitoring and responding to feedback on Twitter, Facebook, all forms of social media. Logic Apps does this really, really well. They have a lot of built-in connectors and adaptors for social media, like I say, I combine that with cognitive services to find out when sentiment gets negative and you can react to problems if you’re a customer-facing company, you can react to problems that customers have at stores in a very timely manner.
Customer communications is another popular branch that I see clients leveraging Logic Apps for. We’re way past the day where customer communication is just an email. Now, we want feedback via surveys. We want to interact with them on mailing lists via MailChimp and then we want to have interaction with them via text messages. Sometimes we want to send them text and get responses back and all that can be very streamlined and done very easily inside of Logic Apps.
Next is cross-team communication. So I’ve seen even within the same client, different teams will use different forms of communication. Especially, if you bring in outside groups that are going to participate in building out solutions. There’s all sorts of different ways that teams communicate. Logic Apps can be used to help bring those all together in a centralized manner. Next is incident management. We kind of saw this in Kent’s talk yesterday from a flow perspective, but definitely leveraging Logic Apps to help workflow your incident management process is definitely a popular scenario I see clients moving forward with.
The next scenario is batching. How many people do batching inside a BizTalk today? Okay, I’ve built many of solutions using batching inside of BizTalk. Try to avoid the convoys at all costs. Usually, we write it to Sequel and pull it out of Sequel Server and in a batch. Logic Apps does batching really, really, really well. It’s a great place to batch messages. They’ve essentially trivialized the batching process inside of Logic Apps. BizTalk, I would definitely say probably not so well at batching. There’s some support for it but tends to be a little cumbersome and tough to recover from errors.
Inside Logic Apps you can batch on any combination of message count, batch size in time, which gives you complete flexibility on how you want to release your batches. And with that, let’s see a demo. Let’s see how we can send messages from our BizTalk Server into a roaming environment of Logic Apps. I’m connected to my virtual machine, which is actually running back in the States, and let’s take a look at what the Logic App would look like for doing our batching solution.
It’s composed of two parts. We have a batching Logic App that is responsible for…it’s a batch trigger is what you use. It receives messages into that Logic App and then when your released criteria is hit it’s going to release that message and do whatever workflow you have with that. In this case here, I’ve configured this batch trigger. There’s two different modes for configuring it, in-line and integration account based. So you can actually configure your batches inside your integration account as well as essentially reference them here if you’d like.
I’m just going to use in-line mode. You give it a batch name. I just called it U.K, and then here you can select the criteria that you want to have setup for releasing this batch. Again, you can select one or more of these. I’m just going to use message account based. So once five messages are received I’m going to go through a compose shape just to kind of reformat the output and then I’m just going to send that message to a Service Bus queue. Now, in coordination with the batch trigger, you also have a batch of action. The batch of action is used inside of another Logic App to send a message to your batching Logic App.
In this case, I’m just receiving a message here from a queue and going to call our batch of process. So when you first add this it will auto-select or give you a drop-down list of available batching or Logic Apps that you can talk with. I simply selected it here. It’s called batcher. You want to make sure the batch name matches so I give it the same name of U.K. and just passing in the content of that message, and that’s all you need to do in order to set up batching inside of Logic Apps. Quite literally, you can set this up in five minutes or less.
Then on a BizTalk perspective, on BizTalk sign, I’ll just show you the sender side of things, setting things, sending single messages to a Service Bus queue. So I’m not doing anything fancy here, just quite literally dropping the file, sending it to Service Bus and then we’re going to pick it up inside there. So let’s go ahead and drop five messages. I’ll show you my batch out. It doesn’t contain anything now. We’re going to drop our five messages. I happen to choose JSON messages, signal messages in. I’m going to drop those, and hopefully those actually dropped. I’m going to…I’ll run it again just in case. Sometimes BizTalk is too quick.
And then I just simply need to…I’m going to manually execute my trigger inside this Logic App just because the polling interval is set for every minute. I don’t wanna sit here and wait for that. So now this is going out and getting those messages from that Service Bus queue and going to execute that. Let’s go over to this completed overview and we should see some executions now around 10:55 a.m. my time. So we come down here, and sure enough, there’s 10 executions because I dropped them twice.
So each individual message started a new instance of this batch collector orchestration, or Logic App. And let’s look at our output messages, our batch out. We got our two batches out, each are going to contain five messages. We’ll take a look at what these looks like. Control+K, control+D to pretty format it and you can see here it’s done just what we expected, batched our messages together inside a single transaction. Now, you’d want to do a little more manipulation on the message, and if you’re receiving XML, do some more formatting and mapping of that data but here I just want to show you the concept of how easy it is to batch these messages inside Logic Apps.
One thing you should note that they did come in out of order. First off, I’m dropping them in a file adapter which doesn’t support order delivery, and I’m also not enforcing order on the bash collector side. If I wanted to do that I definitely could. I could just ensure it goes into the Service Bus in order and then do in order message delivery inside the Service Bus to ensure that they get added to the batch in the correct order.
Okay, I’ve selected who’s that demo of batching inside of BizTalk Server and Logic Apps. I’m using the batching support inside of Logic Apps. It’s one of the few scenarios where I think it does actually make sense to send data on-premise into the cloud just to send it back again, just because I think that batching support is so simple to set up and so robust in the features that provides.
So another scenario I see clients looking at is mapping inside of Logic Apps. There’s near seamless execution between maps that you create in BizTalk Server versus maps that you’re going to execute inside of Logic Apps. You can either call your maps via integration accounts, they’ve got the little star because we know there’s an extra cost with integration accounts, or you can also call them via functions. You can set up an Azure function that does your transform. There’s a cost with that but I’m presuming it’s going to be less than integration accounts.
If you are using your BizTalk Maps verbatim you do need to look at custom functoids and any database functoids your using inside those maps. You need to rework those into either custom.net assemblies or into other Azure functions that you can then call from your maps. There is now support for uploading custom.net assemblies into your integration accounts. You can simply upload your maps and assemblies together and it’s just going to work.
And if you want more information on this there’s a great “TechNet” article. It’s actually two parts on migrating BizTalk Maps to Azure Logic Apps, shortcomings and solutions, walks through everything that we’ve talked about here step by step. It doesn’t talk about putting custom assemblies into integration accounts because that’s a relatively new feature as compared to when this article was written.
The next scenario is inbound de-batching. So BizTalk really does a good job of inbound de-batching. We can de-batch XML messages. We can de-batch flat file messages. It’s pretty simple and straightforward. It runs pretty efficiently inside there. Logic Apps also does a really good job of de-batching. They have native support for de-batching XML messages via an XPath and via a JSON message if you pass in a JSON array. Not all Logic App triggers and scenarios will support auto de-batching at the trigger level. One of those scenarios is if you have a request-response Logic App that’s not going to allow you to shred at the trigger level. You’d have to look at other ways of de-batching, maybe via [inaudible 00:17:39] loop.
So let’s take a look at a demo of this, how easy it is to configure our Logic Apps to do our de-batching. Okay, so we are back in my virtual machine. We are going to take a look at the new Logic Apps here. So we have a Logic App for de-batching JSON messages as they come in. In order to set this up on your HTTP trigger you first need to provide it a JSON schema so it knows the format of the message coming in, and then it’s quite as simple as coming over to the settings over here and go to settings and simply say split on and turn that on and it’ll give you a nice drop-down of the arrays that are listed in that inbound JSON message, and you can simply select here how you want to split up those inbound transactions.
Now, this is going to go ahead and create a new Logic App for each of the inbound messages that match this criteria, so then I’m just doing some formatting and then sending the message to the Service Bus queue. Now, I’m going to set this up in BizTalk. I already set this up for us. We’re going to send our JSON message. This time I’m going to do it slightly a little bit different. I’m going to configure this. I’ve put in the HTTP endpoint that’s exposed via the Logic App right here in my Logic App adapter. I go under messages and this is the key to get this whole scenario to work.
We need to set the content type to Applications/JSON. So as the way I think of it, content type is as important to Logic Apps as message type is to BizTalk Server. There’s a lot inside of Logic Apps that rely on content type being set and being set correctly, just the same as BizTalk Server with message type. So if I was to use a Service Bus queue for this, for example, it’d be more challenging to maintain that content type, but being able to call it via the Logic App adapter I can go ahead and tell it’s going to be a JSON input message.
So let’s go ahead and run that. When to drop in, my batch transaction of JSON has 100 transactions in that, drop it into my large batch in and de-batch messages out. It should start showing up. So after seeing some people having some performance issues with their demos yesterday I was smart and said I’ll create all these Logic Apps in South U.K. but then I didn’t realize I forgot my VM is in the U.S., so totally defeats the purpose. So a little bit of latency here as these are coming in. So these are just our single messages. We can take a look at one of these and don’t need to reformat it. So it’s just a single record that now I can work with.
Obviously, instead of just sending into Service Bus queue I could have done more work to that message in the Logic App, and really the whole goal of doing that in the Logic App is to ensure that when I send it into BizTalk Server on-premise it’s a pure messaging solution from then on. If I can prep that message enough so I just do messaging, hopefully I can reduce maybe some orchestration work that I have running on my BizTalk environment.
So let’s see what it’s like if we have XML. I have a nice Logic App here for that. Unlike the nice support that we saw for JSON, since you don’t have a JSON schema here, by default under the settings section you’re not going to have the ability to select a split on. You have to go under code view, and I simply had to edit the JSON file under the covers here and could put a split on in manually and set it to the XPath of the trigger body and tell it the XPath of the values that I want to split on. Now, once I have that set up, ironically it will now appear in my settings tab. Here I split on. So once I’ve added that it recognizes that it’s there. Again, I’m just sending this out of this Logic App back to Service Bus queue.
So let’s first clean this up, and I delete those 100 messages. Let’s take a look at how we set this up inside of BizTalk Server. I’m going to send my XML message. I put in my same HTTP call but this time I change my content type. This time I said Application XML. If I forget this or leave it as JSON it’s not going to work right when it gets in there because it’s expecting to XPath that message and it’s not going to be able to work. So again, content type very important. I’m going to leave that set, and let’s pass in our class list XML this time and see if these start coming out, and here we go. We’re getting our single messages out just like we saw with JSON and they’re all split under the student note.
Okay, so now we can jump back to our slides. So hopefully, you saw from that how simple it was to set up inbound de-batching. Again, I wanna send messages nicely from BizTalk up to Logic Apps to de-batch like I did here but if you expose Logic Apps externally, you know, it’s good to know that does have support for that de-batching. Obviously, if you needed to send customer emails or customer text notifications you could send that up to Logic Apps in a batch and you’ll know that it’ll be able to split that up and make those individual calls for you to your customers.
The next scenario is inbound FTP/SFTP. I find this to be a common scenario. A lot of BizTalk Servers process these from external providers. Logic Apps has a trigger on the receive side that can and pull in files via FTP and SFTP so that can be a good alternative to running on-prem. Once you get your messages in you could then map, decode, de-batch, log, do as much processing as you can instead of Logic Apps. Again, the goal is to push it back to BizTalk Server when it is a pure messaging based solution then send on-prem for processing.
The other scenario, last scenario we’ll talk about, is to help replace reverse proxies. How many people use reverse proxies today? A lot. I see that a very common scenario, a lot of clients. I was at a client site that had two production reverse proxies and three non-production reverse proxies, something over $20,000 worth of hardware just to receive inbound messages from their clients. If you use a Logic App to replace the reverse proxy you can just send the message to a queue afterwards, this could help save some costs on the hardware side.
You can then map, de-batch, do whatever you need in your Logic App, then great. This is really good for one-way scenarios so you’re not holding that connection open or waiting for a response to come back from an on-premise system. It’s even more useful if you can front this, front your Logic Apps with the API Management. It gives you more flexibility, a good security model around exposing those Logic Apps to third parties.
Okay, with that we’ll move into phase two, friction factors. I just have a few slides here and then you guys can get to your party. Friction factors is different things I’ve seen from different clients that I’ve worked at that are mostly all on-premise. Very few clients that I work with actually do any sort of cloud whatsoever. So I’ve put together some of the reasons why these clients aren’t using cloud and some ways that I think might help them kind of see the light in the cloud.
First and foremost, the number one reason is we already have BizTalk Server running, which of course, that makes sense but just for comparison purposes, though everybody says Azure Logic Apps cost money, we have just, you know, at pre-execution. So I did some math using the nice calculator that they have. If you run 100,000 Logic Apps per day and each Logic App has 2 connectors, so you’re receiving a message and you’re sending a message, and then 4 actions inside that Logic App, it’s going to cost you less than $1,000 a month, which I think that’s a heck of a lot of computing power and a lot of flexibility for a relatively small amount of money. So for the price of, you know, for 3 or 4 months of running 100,000 Logic Apps you could replace one of your reverse proxy servers, for example.
Hopefully, you’ve seen our six scenarios and there’s something that kind of strikes you here that might make sense in your environment to help get that load off your BizTalk Server, help make your BizTalk Server run more efficiently. It’s really about moving workloads to the cloud that can be used to help, make your BizTalk environment turn back into that lean, mean, on-premise messaging processing machine that it used to be, right. It’s really all about making BizTalk Server great again.
I tried to get some balloons to drop but it just didn’t happen. A lot of times I hear customers say the data is too sensitive. This is definitely true in a lot of scenarios, there’s regulatory concerns, there’s legal restrictions around that. So moving that data into Logic Apps doesn’t make sense, but in these scenarios I try to look for non-sensitive workloads such as customer communications, you know, via email, via Twilio, via text message, it makes a lot of sense there.
And another thing I like to point out to clients is, “Really, do you trust your IT security team more than Microsoft’s IT security team?” Most of the time they surprisingly say yes and these tend to be the same clients that give developers full production access, which seems a little bit ironic, but anyway, that’s how it works. Another common scenario is the infrastructure manager flat-out says no. It kind of feels like you’re going to intrude a little bit on his space working with, you know, Logic Apps in the cloud. I found that getting the infrastructure on board early and getting them excited about Logic Apps is kind of key to adoption inside your enterprise if you’re not using Logic Apps already.
So some of the things I like to tell them is, “You know, if you go with Logic Apps I’m going to bother you less. You know, you’re not going to have to have me coming telling you set up dev environments,” for example. We’re not going to need any new servers so they’re not going to have to provision anything new for us to get started with Logic Apps. In fact, we might even reduce on-premise servers. Maybe we can get rid of the reverse proxies, one less thing they have to worry about.
Another thing I like to do is point out the cool IaaS features inside of Azure. A lot of times people are just are unfamiliar with what the IaaS side of Azure can do and, you know, get them on board, give them a little excited about the future that they might have with Azure. Then I try to make them feel really important and I say, “You know, I’ll make you co-admin on the Azure subscription.” You know, kind of make them feel like they’re needed.
So that said, I never recommend developers having any sort of access to the production, Azure subscription. Usually, it is infrastructure ops that is going to own that. So once you get an infrastructure manager on board you’re looking pretty good, get them to switch from a no to a yes. The only thing I commonly hear is there’s a large learning curve for Logic Apps. We’ve invested all this money in learning BizTalk Server now we have to retrain everybody on Logic Apps.
A lot of this is kind of bitter taste in people’s mouths just because BizTalk was such a challenging product to ramp-up on. It takes a lot of time to really become proficient at BizTalk Server. So what I like to say is, you know, if you’ve worked with BizTalk, Logic Apps is going to make complete and total sense. If you’ve built an orchestration you can drag shapes into Logic App just as easily.
I would recommend spending time reading the documentation. I kind of admit that I actually did this. I read the documentation without having a problem. I sat down and read through these three things. These are the three key things I suggest everyone look up, limits and configuration information inside Logic Apps, logic App workflow definitions…the workflow definitions have multiple parts, three different parts in it…and then connectors overview. The connectors overview lists all the connectors that you have access to, any known issues with those connectors, and limits that those connectors may have.
Really about Logic Apps is understanding what you have available to you and these documents help you with that. So once you know what’s available it makes it easier to design solutions. So I would say in 30 minutes of looking at this documentation I would estimate your proficiency in building Logic Apps would go up 2 times or more. It’s quite simply because you know what’s available out there. They also outline the rules of the platform and everything you have to think about in terms of, you know, how many shapes can I execute in five minutes, you know, how many external concurrent calls can I make? All that’s outlined in those documents.
Then I also like to point out to, you know, upper management, if you’re bringing on Logic Apps, you know, Logic Apps is so easy that we don’t need to hire outside consultants like me anymore. I’m sorry, that’s the wrong slide. That is supposed to be hidden. Logic Apps is almost so easy that we almost don’t need to hire external resources anymore, and that’s really what it is. If you’ve seen what they’ve done the past two days, getting 90% there is almost as easy as they make it look like in the demos.
Azure changes frequently, this is another common thing I hear clients talk about. I tend to think this is a great thing, having access to new features. In Logic Apps it’s about every two-week or so release cadence and we have new things that we can do. Things are made easier. Things get easier every day with new features that are added. Frequent change is something new to a lot of BizTalkers. I mean, we’re kind of custom to a little bit longer release cadence than every two weeks. So especially the management teams that tend to manage BizTalk environments also aren’t used to that kind of frequent change.
The way I like to think of this and present this to clients is a JITA approach, a “just in time architecture.” So what this means is I’m going to take whatever is available in Azure today and I’m going to build an architect, the best solution I can, using what’s available today, and as long as the business needs are met and it’s running as expected I’m not going to worry about going back and re-factoring based on new features that might come out later on inside of Azure.
Now, if business needs change or it’s not working right, definitely you’d want to look if there’s better ways to do things but I have Logic Apps that I’ve built two years ago that could definitely be done a lot differently now but they’re working just fine so I’m just going to let them keep humming along. Now, to our last friction point, this kind of the buck stops here in terms of like getting Logic Apps and Azure into your environments. Flat-out the CTO or the CEO says, “No, I’m not doing cloud.”
I had a client like this. The CTO actually totally refused to entertain anything that was cloud-based. This is a tough problem to solve. We solved it by having him retire. Yeah, so he’s on the beach somewhere, and within 30 days of his retirement, every single developer had Azure subscriptions. We sat down for a three-day walkthrough of their plan to move to Azure and what services they could, you know, leverage right away. So with that, thanks. Hope you enjoy your party. Reach out to me anytime if you have any questions, firstname.lastname@example.org. Thank you.
Man: Thanks, Stephen. Thank you very much for the wonderful talk. Stephen didn’t require any introduction because he’s a great community member from 2001 onwards. He’s working with BizTalk from 2000 version onwards. So we took it seriously and we messed it a little bit and we forgot to introduce him. With apologies, thank you very much for the great talk. Thank you very much.
Fill the form below to get all the presentations delivered as a single zip file in your mailbox.
byJon Fancey & Matt Farmer
byMicrosoft Integration Team
Back to Top