can microsoft logic apps re- place microsoft biztalk?1247203/fulltext01.pdf · is microsoft biztalk...

56
Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Linköping University | Department of Computer Science Bachelor thesis, 16 ECTS | Datateknik 2017 | LIU-IDA/LITH-EX-G--17/082--SE Can Microsoft Logic Apps re- place Microsoft BizTalk? An evaluation of integration platforms Anton Berglund Oscar Fredriksson Supervisor : Rouhollah Mahfouzi Examiner : Ahmed Rezine

Upload: others

Post on 14-Oct-2019

11 views

Category:

Documents


0 download

TRANSCRIPT

Linköpings universitetSE–581 83 Linköping

+46 13 28 10 00 , www.liu.se

Linköping University | Department of Computer ScienceBachelor thesis, 16 ECTS | Datateknik

2017 | LIU-IDA/LITH-EX-G--17/082--SE

Can Microsoft Logic Apps re-place Microsoft BizTalk?An evaluation of integration platforms

Anton BerglundOscar Fredriksson

Supervisor : Rouhollah MahfouziExaminer : Ahmed Rezine

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Anton BerglundOscar Fredriksson

Abstract

Integration has always been an important and tricky task for IT-businesses. There areseveral products available for solving integration issues, one of them is the long developedplatform BizTalk from Microsoft. As cloud computing has grown in recent years, Microsofthas been putting more focus towards the cloud. With their cloud, named Azure, expandinga new integration platform have been released, the iPaaS (integration Platform as a Service)Logic Apps.

This report aims to evaluate the integration platforms Logic Apps and BizTalk with thepurpose of finding out if the new Logic Apps can replace the long developed BizTalk. Theevaluation is performed by implementing an application in both platforms, then evaluat-ing selected parameters by giving each a score to concretize our assessment on quantifywhether Logic Apps can replace BizTalk.

Contents

Abstract iii

Acknowledgments iv

Contents iv

List of Figures vi

List of Tables 1

1 Introduction 21.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Theory 42.1 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Logic Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Method 183.1 Choice of the parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Defined parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Implementation 214.1 Message Relay Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Logic Apps implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 BizTalk implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Evaluation and Result 335.1 Evaluation of parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Evaluation rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3 Side Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6 Discussion and Conclusion 466.1 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

iv

Bibliography 49

List of Figures

2.1 Many to many connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 One to many connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Cloud Service Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Azure Function development in Azure portal . . . . . . . . . . . . . . . . . . . . . . 92.5 Logic Apps Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 BizTalk components overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 BizTalk orchestration overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Message-relay overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Message-relay operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Logic Apps Parent workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 Logic Apps Child workflow 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Logic Apps Child workflow 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.6 Logic Apps Child workflow 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.7 Logic Apps Child workflow 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.8 Try-Catch scope in BizTalk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Logic Apps Resubmit run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.2 Logic Apps Map to messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.3 Logic Apps Run History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.4 Logic Apps Detailed Run History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 BizTalk Server map editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

vi

List of Tables

3.1 Rating definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1 Rated exception handling parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 Rated functionality parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 Rated rest of parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.4 Evaluation Total rating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.5 Side Study Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1

1 Introduction

1.1 Introduction

In IT-businesses, the process to connect individual systems to become a larger system work-ing together is called integration.

As the systems used by companies become more complex. As a result the applicationsdeveloped that exchange information needs to be integrated in the system. To integrate thesesystems, engineers often use software called integration platforms.

In recent years cloud computing has grown bigger. With cloud computing, many serviceshas appeared, such as the Software-as-a-Service (SaaS), where a user can use a software whichis not installed on user machines. Using cloud services has many benefits compared to usingsoftware installed locally (on-premise). On-premise software is often more expensive andrequires more configuration and maintenance which can be time consuming. As new cloudintegration platforms emerge, they might be more beneficial for solving integration problems.

Several companies are considering to migrate to the cloud. However, as the new cloudservices are being released, it is interesting to see how these new kind of software can replacethe well developed, stable, on-premise software. Or are they still too immature to be used?

1.2 Background

The host company is a global corporation with around 2000 employees spread across theworld. With employees developing systems on different locations, the systems need to beintegrated.

The company has started to migrate some of its applications and services to the cloud,where it is building a platform. The office in Linköping has around 50 employees and ismainly working with development and integration. Microsoft BizTalk is the current platformused to solve integration issues. The platform is stable, and has been developed since itsrelease in year 2000.

However, as cloud computing is growing, there may have appeared other solutions tosolve integration problems. One of the solutions could be the newly released Microsoft LogicApps which could ease the integration in terms of implementation and maintenance.

2

1.3. Aim

1.3 Aim

The purpose of the study is to determine if the current platform Microsoft BizTalk is replace-able with the newly released Microsoft Logic Apps for the host company by comparing themby literature and with a scenario implemented in both platforms.

1.4 Research questions

The research questions that are going to be answered are the following:

• What aspects of the integration platforms are relevant for the host company?

• Is Microsoft BizTalk replaceable with Microsoft Azure Logic Apps for the host com-pany?

1.5 Approach

To be able to answer the research questions in this thesis, we plan to:

• Read about the platforms, Logic Apps and BizTalk.

• Identify the needs for the host company.

• Choose relevant parameters.

• Implement a scenario in both platforms.

• Evaluate the platforms based on the chosen parameters.

1.6 Thesis Structure

The thesis structure is as follows:Chapter 2 will contain the theory and background on the notions used in the thesis. Chap-ter 3 proposes the method with the parameter that is used to compare Logic Apps andBizTalk. Chapter 4 contains the scenario description and the implementation in Logic Appsand BizTalk. Chapter 5 contains the evaluation of the parameters described in the methodas well as a side study done to test the performance of implemented applications. Chapter 6contains a discussion and the conclusion that was drawn for this thesis.

3

2 Theory

In this chapter the background of the notions that will be used in this thesis will be described.This chapter will be structured as follows. First we generally describe what system inte-

gration and cloud computing is. Then we will describe the cloud service provider "Azure"and some of its services that is used in this thesis, such as the integration platform LogicApps, Azure Function, Blob storage and Service Bus. Lastly the integration platform BizTalkis described as well as the API that is being used in the implementation in chapter 4.

2.1 Integration

Integration is a process where applications or systems are connected to create a larger sys-tem. As the amount of applications and systems within the system increases, the integrationsolution becomes crucial. Imagine a customer calling a support-service and when the sup-port enters the customers’ information. A lookup in a database is triggered and the supportpersonnel can immediately answer if items are in store or sold out. All these systems thattrade information require a connection between each other. Now imagine an organizationwith over thousands of different systems that trade information with each other. Since everysystem needs a single connection to the other systems, the number of connections is going toexceed the number of systems, see figure 2.1. This can be problematic when troubleshootingerrors due to the amount of connections. Adding and/or removing existing systems wouldnot be an easy task either [4].

4

2.1. Integration

Figure 2.1: Many to many connections

An alternative to this problem is to introduce a new central system called an integrationhub, or platform whose purpose is to connect all the other systems. In other words, insteadof all systems being connected to each other, all "small" systems are only connected to theintegration platform whereas the integration platform is connected to all the systems as infigure 2.2. With an integration platform the amount of connections are reduced and the abilityto manage and troubleshoot becomes easier [4].

Figure 2.2: One to many connections

5

2.2. Cloud computing

The integration platforms can be built from components, purchased as a pre-built product,ready to be installed, or used from the cloud. In this paper, we will compare two integrationplatforms, Logic Apps and BizTalk which will be explained later on.

2.2 Cloud computing

Cloud computing, or "the cloud", is a way to store and access data and programs over theInternet instead of having to store the data on your own devices. Several definitions of theword cloud computing have been proposed, although there is no formal definition. However,the following definition has been proposed by U.S. NIST (National Institute of Standards andTechnology) and is the definition that has been used frequently by the cloud computing com-munity. “Cloud computing is a model for enabling ubiquitous, convenient, on-demand net-work access to a shared pool of configurable computing resources (e.g., networks, servers,storage, applications, and services) that can be rapidly provisioned and released with mini-mal management effort or service provider interaction” [8].

Besides the definition, the major advantages and characteristics of the cloud is that theresources should be easy to scale up or down for the consumer based on the consumerscurrent needs and a user only pays for what resources he/she uses [8] [35].

2.2.1 Service models

The three service models can be viewed as a stack as shown in figure 2.3 [8] [35].

Figure 2.3: Cloud Service Models

2.2.1.1 Software as a Service

Software as a Service (SaaS) is exactly what is implied by the name, a software as a service.Users’ applications are deployed in the infrastructure of the cloud which means that the userdoes not know or even needs to know any details on the underlying infrastructure, it is in-stead handled by the provider. The user has no control of the network, servers, operatingsystem, storage or the application capabilities. A SaaS service can be accessed from variousdevices through a program interface or directly through the web without the need to installa program on the users own computers, the user may however need to install the plug-ins.Google Mail, Google Docs and Facebook are few examples of SaaS applications [8] [35].

6

2.2. Cloud computing

2.2.1.2 Platform as a Service

Platform as a Service (PaaS) is a development platform that allows the developer to createapplications without the need to buy software and/or hardware to meet the applications re-quirement that also needs maintenance, PaaS solves this. PaaS covers the whole "softwarelife cycle", i.e PaaS hosts development infrastructure, configuration management, testing, de-ployment of the software etc. This allows the developer to focus on the application withoutcaring about the underlying infrastructure. The difference between SaaS and PaaS is that SaaSonly hosts completed cloud applications whereas PaaS hosts the whole life cycle [8] [35].

2.2.1.3 Infrastructure as a Service

Infrastructure as a Service (IaaS) is a way to deliver infrastructure as an on-demand service.Compared to SaaS and PaaS, the user in IaaS is responsible for the applications, storage,network services (firewall) and OS. The user is however not required to purchase physicalservers but can instead purchase the IaaS infrastructure and thus easily regulate the amountthey need [8] [35].

2.2.1.4 Integration Platform as a Service

In all the three models of cloud computing(SaaS, PaaS and IaaS), some sub layers exist. Oneof them is the integration Platform as a Service(iPaaS). Similar to PaaS, iPaaS offers a cloudplatform for developing software/web-applications as well as building and deploying inte-gration within the cloud and between the cloud and the enterprises. The user can developintegration flows that enable connectivity to SaaS and other applications in the cloud. Theuser can also create connectivity to on-premise applications without installing any new soft-ware or managing hardware or middleware [26] [6].

2.2.2 Deployment models

2.2.2.1 Private cloud

For a "private cloud" the infrastructure of the cloud is operated exclusively within a singleorganization and managed by the organization itself or a third party, it may be located on-premise or off-premise. Key benefits for using private cloud are security, any confidentialdata is in the organization’s hands at all times [8] [35].

2.2.2.2 Community cloud

For a "community cloud" the infrastructure of the cloud is operated by a specific community,i.e several organizations that share the same concerns, such as security. It may be owned,managed and operated by one of the organizations in the community, by a third party or bya combination of them. A community cloud may be located either on-premise or off-premise[8] [35].

2.2.2.3 Public cloud

The "public cloud" is the most common form of cloud computing deployment model, thecloud infrastructure is open to the general public for the consumers to use according to theservice provider’s policy. It is located on the premises of the cloud provider. An example ofthose public clouds are Microsoft Azure, Amazon EC2 and Google App engine [8] [35].

7

2.3. Azure

2.2.2.4 Hybrid cloud

For a "hybrid cloud" the cloud infrastructure is a combination of two or more clouds (pri-vate, community and/or public) that remain unique entities but are bound together by stan-dardized or proprietary technology that enables data and application portability ( e.g. cloudbursting for load-balancing between clouds) [8] [35].

2.3 Azure

Microsoft Azure, previously known as Windows Azure, is a cloud computing platform andinfrastructure for creating, managing and deploying applications. Azure offers all three mod-els of cloud computing as mentioned earlier in 2.2.1, the SaaS, PaaS and IaaS. Azure servicescan be accessed through the Azure web portal, and most of services have also been integratedin Microsoft Visual Studios as extensions [3] [12].

2.3.1 Off-premise Azure versus on-premise services

With an on-premise infrastructure, the control of the hardware and software is in the handsof the user. This is not always entirely positive. With an expanding organization this forcesenterprises to develop their own private data centers and that is usually both time-consumingand hard to scale. In addition, the enterprise has to weigh of being able to expand to meetfuture needs on one hand and not purchasing too much hardware on the other hand (sincethat will most likely not be an efficient way of handling the companie’s money). Anotherdownside with having to establish several small computer centers is that they are not asenergy efficient as having one large computer center [35] [27].

Azure handles all these problems, all hardware is provided by Microsoft and the user onlypays for what services they procured, and that obviously makes it easier to scale the requiredcapacity up or down from one time to another. Another benefit with Azure is that the usercan easily change between software/OS etc without the need to install the software on theirhardware [3].

Despite the benefits of cost and easy scaling, Azure still has some general flaws which isgeneral to all cloud computing services. Since all hardware is hosted and located on anothercompanies premise, the user has no control over it. For some companies that aspect is asecurity concern. All companies hold some data they consider confidential and by cloudcomputing the company will deposit that data to a third-party [27].

However, some of these issues have been solved with the above mentioned hybrid solu-tions which host a part of the system on cloud providers’ system while other, more importantand critical parts or data are located on the local machines. This ensures the security andprivacy of a company’s data by keeping it under the company’s control whilst at the sametime making it more reliable to its customers [3].

Since it is a hybrid solution, a connection is needed between Azure and an on-premisedata center. To solve this Azure developed Azure Service Bus. The on-premise data center isconnected to the cloud by using the Service Bus and the data can be accessed [3]. The AzureService Bus will be explained in 2.3.2.3.

2.3.2 Azure Services

Azure provides a number of services and is increasing all the time. In the 2013 book "Intro-ducing Windows Azure For IT Professionals" it was said that Azure Services could be brokendown into four categories; compute, network, data and app services. Since 2013 there hasbeen such an increase that four categories do not suffice anymore. As of 4 march 2017, thereare 11 different categories [33] [11].

8

2.3. Azure

In this thesis, the Azure Services that are going to be used are Service Bus, Blob storage, LogicApps and Azure Functions.

2.3.2.1 Azure Functions

Azure Functions are a way to write a small piece of code, a function, in the cloud and integrateit with your solution. With Azure Functions it is only needed to write the code to solve theproblem at hand and there is no need to worry about the infrastructure or the application thatwill run it. It currently supports several code languages, such as C#, F#, Node.js, Python andPP. Azure Functions can be either coded and tested in the Azure portal as shown in figure 2.4or in Visual Studios [7].

Figure 2.4: Azure Function development in Azure portal

2.3.2.2 Blob Storage service

Blob storage is an Azure service for storing data objects, such as text or binary data, whichis accessed with the HTTP or HTTPS protocol. The stored data can be public for anyone toaccess it or store the data privately. The blob storage can be used for a variety of things suchas: [3] [14]

• Serving images or documents directly to a browser.

• Storing data for backup and restore.

• Storing data for archiving.

• Storing data for analysis by an Azure-hosted or on-premise service.

The Blob storage service consists of three main components; Store account, Container andBlob [14].

• Store account - A storage account is used for accessing the Azure Storage. There are twodifferent storage accounts, a General-purpose storage account or a Blob storage account.The General-purpose storage account gives access to Azure Storage services such as

9

2.3. Azure

Tables, Queues, Files, Blobs and Azure virtual machine. The Blob Storage account isspecialized storage account for storing unstructured data as blobs in Azure Storage.

• Container - The container’s purpose is to group a set of blobs, a blob is required to be ina container. A blob storage account can have an unlimited number of containers, and acontainer can store an unlimited number or blobs.

• Blob - A blob is a file and can be of any type and size. There are three different types ofblobs:

– Block blobs - A block blob can contain up to 50,000 blocks of up to 100 MB each fora total size of approximately 4.75 TB. Block Blobs are often used for storing text orbinary files.

– Append blobs - Append blobs are also made up of blocks like block blobs, butappend blobs are optimized for append operations which makes it useful for log-ging. An append blob can contain up to 50,000 blocks up to 4 MB each for a totalsize around 195 GB.

– Page Blob - A Page blob is more efficient than a block- or append blob for frequentread/write operations. A Page blob can be up to 1 TB in size which makes AzureVirtual Machines to use page blobs as OS and data disks.

2.3.2.3 Azure Service Bus

In the cloud, applications often need to exchange information or interact with other appli-cations or services. The Azure Service Bus is a way to enable communicating (exchanginginformation) over the cloud. The service bus works as a postal service in the real world, whentwo or more parties want to exchange information the service bus works as a middlemanreceiving and delivering the message to its intended recipient. The purpose of the servicebus is to make communication easier and asynchronous where both parties do not need to beconnected at the same time. The service bus offers three ways of communication: [3] [2] [22]Queues - Allow a one-way communication. The queue acts as an intermediary (also called abroker) that stores messages in the queue until they are received. Each message can only bereceived once by a single recipient.Topics - Provides a one-way communication using subscriptions. Same as a queue, a topicacts as a broker, but each subscription can use a filter to only receive messages that match aspecific criteria. A topic is able to have multiple subscriptions.Relays - Provides a bi-directional subscription. However, unlike queues and topics, it is not abroker so it does not store in-flight messages. It passes them on to the destination application.

In this thesis an Azure Service Bus Queue was used, and therefor only the queue will beexplained further.

The queue uses the FIFO (first-in-first-out) principle to relay their messages. This meansthat messages are expected to be received and processed by the receivers in the order thatthey were added to the queue, and each message can only be received and processed by onerecipient.

There are two ways to receive a message from the queue, which are called ReceiveAnd-Delete and PeekLock. With ReceiveAndDelete a message is read from the queue and imme-diately deleted from the queue. However if the receiver for example crashes before it hasfinished processing the message, the message will be lost. It is a simple procedure, but it hasbeen removed from the queue so no other receiver can access it. This is however solved withPeekLock. PeekLock reads a message from the queue but it does not delete it. Instead it putsa lock on the message, receiving a lock-id and making it invisible for other receivers and waitfor one of three events to occur: [2] [22]

10

2.4. Logic Apps

• If the receiver manages to successfully process the message, it calls Complete() with thelock-id and the message is deleted from the queue.

• If the receiver cannot successfully process the message, it calls Abandon(). The queuethen removes the lock from the message which makes it available to other receivers.

• If the receiver neither calls Complete() or Abandon() within a configurable amount oftime (default set to 60 seconds), the queue assumes that the receiver has failed. It thenbehaves as the receiver had called Abandon(), which as mentioned above makes themessage available to other receivers.

2.4 Logic Apps

Due to the fact that Logic Apps was made available in 27th july 2016, there are not muchliterature on the subject yet and most of the information is taken from Microsofts website,blog and forum as well as private blogs and forums [10].

Microsoft Azure Logic Apps is a cloud service, an Integration Platform as a Service (iPaaS)which let the developers to not care about scalability, hosting, availability or management. Bybeing a cloud service as mentioned in ??, the user only pays for what the user uses. Funda-mentally, Logic Apps is a "block building" type of programming that enables integration andeasy creating applications by using the visual designer which requires minimal code [18].

Some advantages of using Logic Apps according to Microsoft [18]:

• Saving time by designing complex processes using easy to understand design tools.

• Implementing patterns and workflows seamlessly, that would otherwise be difficult toimplement in code.

• Customizing your logic app with your own custom APIs, codes and actions.

• Connect and synchronise separate systems across on-premises and the cloud.

• Build off of BizTalk server, API management, Azure Functions, Azure Service Bus withintegration support.

2.4.1 Developing a Logic App

Developing a Logic App can be done by either using the Azure portal or Microsoft VisualStudios. For the Azure portal all that is needed is a web browser, whilst Visual Studios requirethe following [18] [16]:

• Visual Studio 2015 or later

• Azure SDK 2.9.1 or later

• Azure Powershell

• LogicApps Visual Studio Extension

• Access to the web when using the embedded designer

A logic app is in essence, a set of building blocks that work together to construct a processthat orchestrates integrations between various parts. Building a Logic Apps consist mainlyof five fundamental components: workflows, triggers, actions, connectors and flow controls,see Figure 2.5. From the workflow point of view, the action, connector and flow control areessentially called an "action", but for the purpose of explaining, we have chosen to separatethese components [18].

11

2.4. Logic Apps

Figure 2.5: Logic Apps Components

WorkflowA workflow is the whole logic app application, the process from start to finish. That is from atriggered event until all inserted parts in the logic app have finished running. Each logic appdefines a workflow, the minimum requirements are to have at least one trigger, then followedby one or more actions and optionally flow controls [18].

TriggerA trigger is an event that starts the logic apps workflow based on a specific event. A triggercan start the workflow without passing any parameters, or have an initial message associatedto it. There are two ways of initiating a run of the logic app, by either a polling or a pushingtrigger [18].

ConnectorThe connector is one of the most basic elements in Logic Apps. Connectors are simply put,

code elements bundled together to allow connectivity to a service. Each connector defines itsown API and require some information to be configured in order to connect to the specificservice. For example the Outlook-connector, all that is needed for the developer to have anoutlook account and supply his/her credentials. In the figure 2.5, the outlook is a connector,using a connector in a workflow is called an action [18].

ActionAn action executes one step in the logic apps workflow after the triggered event. An actionis typically a connector or a flow control in the workflow [18].

Flow ControlThe flow control allows the user to control the flow of execution of the workflow. That isusing the data from a trigger or previous action and analyzing it. Logic Apps have four typesof flow control: conditions, for-each loop, do-until loop and scope [18].

12

2.5. BizTalk

2.5 BizTalk

2.5.1 What is BizTalk?

Microsoft BizTalk Server is a middleware system. Like Logic Apps, its purpose is to connectvarious systems together. It was first released year 2000, making it a well documented andstable platform. Unlike Logic Apps, BizTalk is an on-premise software, meaning it must beinstalled and configured on a local machine.

2.5.2 BizTalk Engine

BizTalk server can be described as an engine, which consist of two parts. A message com-ponent which communicates with different pieces of software. The software communicatingwith the BizTalk server can be diverse and often different protocols. However, BizTalk’s mes-sage component contains a variety of adapters for different protocols and data formats toenable all kinds of communication. The other part is called an orchestration which allowsyou to create and run graphically-defined processes.

There are several other technologies that are a part of the engine: A Business Rules Enginewhich allows evaluating complex sets of rules. A Health and Activity Tracking tool whichallows administrators and developers to monitor and manage the engine and orchestration itruns. An Enterprise Single Sign-On facility, which provides the ability to map authenticationinformation between Windows and non-Windows systems. A Business Activity Monitoring,which allows information workers to monitor a running business process. The informationbeing displayed is displayed in business rather than technical terms which allows the busi-ness people to be in control of what is being displayed. A Business Activity Services, whichallows information workers to set up and manage interactions with trading partners.

2.5.3 How does BizTalk work?

Figure 2.6: BizTalk components overview

13

2.5. BizTalk

A message is received in a receive location. An adapter picks up the message and passes itto a receive pipeline. Here the message gets decoded, validated, depending on the pipeline’sconfiguration. The message then gets placed in a MessageBox database. From the Messagebox, the message can be passed to the orchestration if the orchestration subscribes to the typesof messages, where it gets processed and passed back to the Message Box. The message thengoes through a send pipeline where it can get encoded, assembled, and then lastly, to a sendadapter.

2.5.4 BizTalk Server Administration Console

The BizTalk Server Administration Console is a program from where the user can configure aBizTalk application. Here the user can also view events that have been logged, suspended andterminated messages, see an overview of the amount of critical errors and warnings that hasoccurred. Suspended messages can be resumed or terminated from here and the suspendedmessages can be grouped by application, enabling the user to know which message belongsto which application.

The BizTalk Server Administrator Console is also from where the users start their appli-cation. After deploying the project in visual studios, the application must be configured andstarted from BizTalk Server Administration Console in order to run. Applications can also berefreshed in case where a small change has been made to the project.

There are various logs that can be viewed in the console, such as the application log,security log or hardware log, depending on the events. These logs are possible to write tofrom the BizTalk orchestration.

2.5.5 Adapters

An adapter in BizTalk is a software component which sends a message from BizTalk, or re-ceives a message to BizTalk. Adapters are needed for connecting systems which might usedifferent data protocols, and the adapters thus enable the systems to communicate with eachother [9].

When a message is passed to the adapter, it writes meta data to the message, such as whatendpoint it was received from. This information will later be used in the BizTalk engine.

By default, BizTalk has "common" adapters such as FILE, FTP, HTTP and SQL, but it ispossible to create your own adapter, to solve specific problems with the BizTalk AdapterFramework. There is a vast amount of third-party adapters, such as the Gmail BizTalkAdapter, which can be downloaded and used.

Adapters can be configured and modified in the BizTalk Server Administration Consoleto your own preferences.

As for BizTalk Server 2013 R2, a Service-Bus adapter has been added, which lets the userto send and receive messages to a Microsoft Azure Service Bus [25]. This makes it possiblefor more hybrid solutions, combining on-premise and cloud computing.

2.5.6 Pipelines

There are two types of pipelines in BizTalk,"receive pipelines" and "send pipelines". Receivepipelines handle a message after it has been handled by a receive adapter, and the sendpipeline handle a message before going out to a send adapter. A pipeline has a set of stagesit goes through, and since receive pipelines and send pipelines work differently, they havedifferent stages they go through.

A receive pipeline consists of four stages:

• Decode

• Disassemble

14

2.5. BizTalk

• Validate

• Resolve Party

A send pipeline only consists of three stages:

• Pre-assemble

• Assemble

• Encode

By default, all stages are empty, but they can be configured with components to the users’own preferences [21]. For example, an XML Validator pipeline component can be added tothe validate stage of a receive pipeline. The said component can be configured to validatea message against a specific schema, or the pipeline will not process the message and besuspended. Another example could be to add a JSON encoder component to the encodingstage in the send pipelines, so the XML message converts to a JSON message before goingthrough the send adapter.

2.5.7 Message Box

The Message Box in BizTalk is a very central component which consists of two components:a Messaging Agent and one or more Microsoft SQL Server databases. In the message box,messages are stored after they have gone through a receive pipeline and can be processed tobusiness processes who subscribe to certain messages.

2.5.8 Schema

All messages processed in BizTalk are based on the XML Schema definition language, andare referred to as a schema. Schemas can be used to validate structure of a message receivedto BizTalk. Schemas can be created manually or with a wizard. By using the wizard, it ispossible to enter a JSON message as input and the wizard will construct a schema based onthat. It can also be done with a flat file.

Since all documents handled by BizTalk are XML, all schemas need to be transformed toXML before they can be processed. This is not necessary if the schema is a so called XMLschema, which is one of four types of schemas that exist. The remaining types of schemasthat need transformation before being processed are flat file schemas, envelope schemas andproperty schemas

2.5.9 Maps

In BizTalk, a map is used to transform data from one document to another. A map is definedin the BizTalk Mapper of a BizTalk project. Transformation between a source document and atarget document can be as simple as copying the values to the other, or more complex usingso called functoids to perform more complex transformations. A functoid can be describedas a function which uses the input data to perform mathematical operations, conversions,logical operations etc.

When a map has been created it can be used in the BizTalk orchestration to perform theconfigured transformations.

2.5.10 Business Activity Monitoring

Business Activity Monitoring (BAM) is a monitoring feature shipped with BizTalk Server.BAM can capture data that is going through the business process, to a set of databases, whereit becomes available to the end-user or other applications.

15

2.5. BizTalk

The monitoring of an application is done in the BAM portal. A business who would liketo see how the business process is going can monitor how the application behaves. A B2Bprocess can take days, weeks or even longer, so watching the process can be relevant for thebusinesses involved, and BAM makes that possible.

2.5.11 Orchestrations

A BizTalk orchestration is a graphical view of the business process. It is in the orchestrationyou can modify your application to e.g receive a certain message, perform a certain transfor-mation or handle errors using scopes. Action shapes from the toolbox in the editor can bedragged and dropped to the design surface, which lets you do relatively much without hav-ing to write a lot of code. The shapes in the orchestration can often be configured or modifiedto specific behaviours.

Messages are passed from the message box to an orchestration if they match a subscriptionan orchestration has. When an orchestration has processed a message, the message is sentback to the message box and through a send adapter.

Figure 2.7: BizTalk orchestration overview

Figure 2.7 shows a print screen of a BizTalk orchestration. The expression editor is visi-ble when editing an expression shape from the toolbox to the left. In the expression editorvariables can be handled as well as tailor made event logging.

2.5.12 .NET Helper classes

Help classes can be used in BizTalk to add extra functionality to the orchestration. A helpclass is a C# file which BizTalk can use by adding a reference to the assembly of the helpclass. Variables from the BizTalk orchestration can be passed to functions of the help class.E.g. The variable string x can be passed to a function in the help class that has a string in itsparameter list.

16

2.6. Miscellaneous

2.6 Miscellaneous

This section contains further background areas of which are important to the theory as theyare used later in the implementation.

2.6.1 Web API

In the implementation which will be presented in section 4 a REST API is used.An Application Programming Interface (API) is a set of definitions, protocols, tools etc

for building application software. A Web API is an API for the web, a web server or webbrowser. In the simplest terms a Web API enables applications to communicate with eachother by using the same language. Since its over the web, the communication is defined as astructure set of HTTP request and HTTP response messages, which is usually in the form ofthe universal XML or JSON format.

2.6.1.1 REST/RESTful API

REST (REpresentational State Transfer) defines a set of architectural principles for designingweb services. REST sends a URI to transfer messages between applications using universalHTTP protocol. Because of this, in recent years REST Web services have become predominantas a Web service design model due to their lightweight communication between applications.Thanks to this lighter weight communication, REST is popular for building cloud-based APIs.When a Web service uses the REST architecture, they are called RESTful APIs or REST APIs.When designing a REST API, four design principles should be followed: [28]

• Use HTTP methods explicitly and in a consistent way to interact with different re-sources. That is use GET for retrieving a resource, POST to create a resource, PUT/-PATCH to update a resource and delete for removing a resource.

• Interaction should be stateless, that is each request by the client should include all theparameters, context and data needed within the HTTP headers and body for the serverto generate a response.

• The interaction between the client and resource in the server should be done by sendingURIs only.

• A REST API should support JSON and/or XML as the format for exchanging data inthe request/response or in the HTTP body.

2.6.1.2 Swagger

Swagger is a framework for describing API’s. Swagger has a user interface that can be viewedin any web browser, from which it being automatically generated from any API defined inthe specification [32].

17

3 Method

In this chapter the method is presented with the parameters that are being used to evaluateLogic Apps and BizTalk. This chapter starts with a presentation of the choice of the parame-ters, followed by how the parameters were defined and finally present how these parameterswill be evaluated.

3.1 Choice of the parameters

We propose to evaluate Logic Apps and BizTalk by comparing different parameters. Theseparameters were based on literature studies and on discussing the needs for the company.Besides literature, a typical application scenario for the host company will be implemented inLogic Apps and BizTalk in order to evaluate the platforms. The scenario and implementationwill be described in chapter 4. The parameters listed below are what we believe are essentialareas in integration solutions which are important to consider when choosing an integrationplatform.

• Exception-handling

• Deployment

• Ease-of-use (Drift)

• Functionality

• Version control

• Logging

• Community

• Support

• Continuity in development

18

3.2. Defined parameters

3.2 Defined parameters

In this section, we describe the parameters in each area and the basis for how we have definedthem, that is what is being investigated.

• P1 - Exception handling

• P1-1 Is it possible to handle specific thrown exceptions?

• The following exceptions are taken in regard of the scenario implemented in chapter4. These exceptions were chosen in regards of the scenario and by requests from thehost company. Other exceptions exist, but these are the ones that are important for thescenario.

– P1-2 - Suspend a message that could not be processed.

– P1-3 - Resubmit a failed run.

– P1-4 - Make sure that a message does not disappear in the service bus.

– P1-5 - Extracting a message from the service bus. (Critical that a message does notdisappear)

– P1-6 - If the SMTP-server is down.

– P1-7 - If the blob storage is down.

– P1-8 - If the message is corrupt, could not be parsed.

• P2 - Functionality (does the platform support/have the following functionalities?)

– P2 - 1 Nested loops

– P2 - 2 Adding / Altering workflow

– P2 - 3 Variables

– P2 - 4 Pre-integrated connectors/adapters

– P2 - 5 Map to other messages

• P3 - Version/source control

– P3 - 1 Is it possible to use Git or any other version/source control with the plat-form?

• P4 - Drift

– P4 - 1 What possibilities are there to monitor the application?

– For P4-2, P4-3, we asked a person that had no part in the thesis and had no knowl-edge of BizTalk or Logic Apps. We described the application and the requiredsteps for handling an error.

∗ P4 - 2 How much knowledge is needed about the application(scenario) itselfin order to maintain it?

∗ P4 - 3 What actions are needed in case an error in the application occur.

• P5 - Development/Deployment

– P5 - 1 What software are needed for developing respectively deploying an appli-cation?

– P5 - 2 What steps are required for deploying an application?

• P6 - Business activity tracking and logging

19

3.3. Evaluation

– P6 - 1 Is it possible to log and trace events in the platform?

• P7 - Support

– P7 - 1 Does Microsoft offer any commercial support for the platform?

• P8 - Community

– P8 - 1 How active is the community? During a time span from when we started16/1-2017 to 24/3-2017 we have looked at how many posts have been posted onMSDN Forums-section as well as Stackoverflow with the tag “logic-apps” and“biztalk”. Also look for if there are any other community sites [31] [30].

• P9 - Continuity in development

– P9 - 1 Is the product being developed?

– P9 - 2 Has the product had any “major” releases in recent time or is a release an-nounced in the near future?

3.3 Evaluation

These parameters will be evaluated regarding literature and our point-of-view from imple-menting the scenario which will be described in chapter 4 for Logic Apps and BizTalk. Be-sides these parameters, a side study will be performed on the implemented scenario to showthe run latency performance for the application. The side study will be described in 5.3.Each parameter will be rated a number based on the definition in table 3.1.

Rating Definition

1 Platform has no support/documentation for the parameter

2Platform has none-to-little support/documentation for the parameter,some difficult workarounds, tailor made solutions or time consumingsolutions are needed

3Platform has some support/documentation for the parameter, someeasy workarounds, tailor made solutions or small time consuming so-lutions are needed

4 Platform has full support/documentation for the parameter

Table 3.1: Rating definitions

20

4 Implementation

In this chapter the scenario is presented followed by the implementations made in BizTalkand Logic Apps.

4.1 Message Relay Scenario

The scenario is called "Message Relay" and, as the name suggests, it is going to relay mes-sages. As mentioned in 1.2, our hosting company has started migrating its business to thecloud. With this approach they are currently developing a new platform in the cloud for theirservices, applications etc. Handling notifications about the services, applications etc. in anyformat is a part of this platform, however since it is being developed, email is one of the firststeps of notification handling.

Implementing a typical application in both Logic Apps and BizTalk for the company, willhelp us evaluating the parameters described in chapter 3. The evaluation of the parametersmade from the implementations and literature will be presented in chapter 5.

An overview of the Message Relay scenario can be seen in figure 4.1:

• A sending system is going to send a message to a queue. (The sending system is beyondthe scope of the study, we do not care what happens before the message have enteredthe queue.)

• From the queue, an integration hub containing the application is going to poll the mes-sage from the queue.

• The integration hub is going to use a mail service to send an email.

The Message-Relay application is going to:

• Receive a JSON[34] formatted message in a service bus queue.

• Get a file containing blacklisted emails from blob storage.

– Remove all the recipients that match any blacklisted emails in the file.

• Get attachments from blob storage.

21

4.1. Message Relay Scenario

Figure 4.1: Message-relay overview

• Get message body from blob storage.

• Send mail to designated recipients with specified content.

The scenario is supposed to be integrated in a larger system. Due to this it is not necessaryto know what happens before a message is received to the queue. All that is needed to knowis what format the message is going to be in and the fundamental operations.

Figure 4.2: Message-relay operations

Figure 4.2 explains a more detailed behaviour of the scenario. The numbers on the arrowsdescribe the order of actions performed and each number mean the following:

22

4.1. Message Relay Scenario

1. Send message body

2. Send message attachment

3. Send message envelope

4. Poll queue

5. Return message envelope

6. Request message body URL

7. Return message body URL

8. Request message body

9. Return message body

10. Request message attachment URL

11. Return message attachment URL

12. Request message attachment

13. Return message attachment

14. Send message

Every message contains the following format, where it could contain one or more items:

{"items": [{

"richKey": "2233223d","type": "Email","data": {

"from": "[email protected]","subject": "This is the subject for the email","bodyBlobUID": "123227668","to": [

"[email protected]","[email protected]"

],"cc": [

"[email protected]"],"bcc": [

"[email protected]"],"encoding": "System.Text.UTF8Encoding","isBodyHtml": true,"organisationUID": "00000000-0000-0000-0000","attachmentBlobUIDs": ["123227668"]}

}]}

23

4.2. Logic Apps implementation

Code Snippet 4.1: JSON Message formatThe storing of the body and attachment is being handled by another application that be-

yond the scope of the study. The richKey and bodyBlobUID/AttachmentBlobUIDs are usedto map to the specific file from the blob storage. This is being handled by an API, which alsois out of scope. An API was built to mimic the behaviours but does not have the same func-tionality as the real API would have. This API was built a little different in Logic Apps andBizTalk, both will be explained in the respective implementation sections."BCC" is only handled in the Logic Apps implementation. BCC is not handled by the SMTPadapter in BizTalk but must be solved with a helper class. "Encoding" and "organisationUIDs"is not going to be handled or used in this application at this point. These values are beingused by other applications before they reach this application and these might be added lateron if the company decides it. But at this point, they should exist but are not to be used.

4.2 Logic Apps implementation

This section describes the different areas used in the implementation of the scenario in LogicApps, and how they were implemented. The subsections do not appear in the same order asthe application were implemented in. The development of the Logic App was done using theAzure Portal with the Mozilla Firefox browser.

4.2.1 Workflow

The parent workflowThe parent workflow as shown in 4.3 takes a message from the SB-queue and parses it ac-cording to 4.1. If parsing is unsuccessful a mail is sent to the drift personnel for inspection.If successful, a foreach loop is used to send each item to a child logic apps. This is becauseit is not possible to handle a foreach inside a foreach, since each items is an array with sub-arrays such as "to","cc" etc, a child logic app is needed. Lastly, if the message is successful, itcompletes the message and removes it from the SB-queue.

The child workflowThe child workflow takes in one item and does the operations as mentioned in figure 4.2 withsome added exception handling. The workflow is described in the following figures 4.4, 4.5,4.6 and 4.7.

24

4.2. Logic Apps implementation

Figure 4.3: Logic Apps Parent workflow

Figure 4.4: Logic Apps Child workflow 1

25

4.2. Logic Apps implementation

Figure 4.5: Logic Apps Child workflow 2

Figure 4.6: Logic Apps Child workflow 3

26

4.2. Logic Apps implementation

Figure 4.7: Logic Apps Child workflow 4

4.2.2 Azure Function

Some help function were needed, these were developed in the Azure portal.BlacklistThe Blacklist-function takes in the "to", "cc", "bcc" arrays and the "blacklistedemails" arrayfetched from the blob storage. It checks if an email address in "to","cc","bcc" exist in "black-listedemails" and if it does, it is removed. The function also joins all addresses to position 0with a delimiter ";" after each address.Validate email address formatThe outlook-action requires that an address contains a valid email format. To solve thisthe .NET Frameworks System.Net.Mail Namespace[24] was used. Every address a Sys-tem.Net.Mail.MailAddress tries to be constructed, if it is unable it is sent back to the LogicApp containing invalid email addresses.

4.2.3 Web API mock

The web mock was developed in Visual Studio 2015 using ASP.NET which is part of the .NETframework. The API receives a JSON object containing richKey and blobUID as shown below4.2. The API responds with a message format containing information shown below 4.3. Sincethis API only mimic the behavior it does not have the same functionality, i.e mapping therichKey and blobUID.

{"richKey": "string","blobUID": "string"

}

27

4.3. BizTalk implementation

Code Snippet 4.2: JSON request object Logic Apps

{"url": "string","uid": "string","mimeType": "string","fileName": "string","fileSize": "int","disposition": "string"

}

Code Snippet 4.3: JSON response object Logic AppsFor this application, the values that are important are the "url" and "fileName". The url is

the url to a file that exist in blob storage, and the fileName is the name of that file. The rest ofthe parameters are not being used for this application.

4.3 BizTalk implementation

This section describes the different areas used in the implementation of the scenario in BizTalkand how they were implemented. The subsections do not appear in the same order as theapplication were implemented in.

4.3.1 Setup

Installing BizTalk requires installing and configuring various software and the total installa-tion time for one machine is estimated to take 4-6 hours according to the Microsoft tutorial[17]. Luckily, the company had an image where BizTalk already was installed and set upwhich we used. This saved us a lot of time. Instead of having to install and configure therequired software from scratch, we only downloaded and installed Oracle VM VirtualBoxManager and setup a virtual machine from the given image.

4.3.2 Logging

Errors and warnings are logged automatically to event logs. It is also possible to write yourown log events to the log. This is however considered as bad practice since it fills the log withunspecific event id’s, but easy to implement, and was done a few times when troubleshootingthe application.

4.3.3 SB-Messaging Adapter

The Service Bus (SB-Messaging) adapter is used to receive messages from the service busentities (Queues, Topics or Relays). SB-Messaging adapter can be used to bridge connectivitybetween Microsoft Azure and on-premise BizTalk servers, which allows users to create hybridapplications.

This adapter was used to receive the JSON message to BizTalk. A Microsoft Azure ServiceBus queue was created in the Azure Portal, where the JSON messages going to the BizTalkapplication could be stored and received from. For BizTalk to be able to receive messagesfrom the queue the queue must be without partitioning. This option can be configured whencreating the queue, but since BizTalk was used, we created the queue without partitioning.The adapter was then configured in the Administrator Console.

The structure of the JSON message has the same structure as in code snippet 4.1.

28

4.3. BizTalk implementation

4.3.4 Try/Catch

In BizTalk, the user can perform a similar try/catch action by using scopes. The scope throwsan exception in case an error has occurred, and the catch scope which follows the scopecatches it.

Every catch scope in our implementation is catching General Exceptions, this is becauseof two reasons:

1. By catching a general exception, the user does not get an exception object on whichthe user can perform actions on, as he/she would get if they were to catch a specificexceptions.

Since we do not know how we would handle the exception object, there was no reasonfor us to get one.

2. General Exceptions covers most of the possible exceptions that can be thrown.

Since we do not know all of the exceptions that can be thrown, it is safer for us to catchthem all. If we catch an exception, the message will be suspended and it can then beexamined if the message is incorrect or not.

Figure 4.8: Try-Catch scope in BizTalk

The exception handling was mainly implemented where the orchestration were commu-nicating with a service outside BizTalk. A scope was therefore added to where the communi-cation could fail, with a following catch scope to handle the exception. This was implementedusing a bool variable and a loop which would loop until the communication succeeded. If anexception were thrown and caught in the catch scope, the loop variable would be set to false.Then the variable was checked in an if statement, whether the variable was false or not. If the

29

4.3. BizTalk implementation

loop variable was false, meaning an exception was thrown, the orchestration would suspendthe message. If it then later were resumed, the loop variable would be set to true so the loopwould run again and retry the communication. If the loop variable was true, meaning noexception was thrown, the loop variable would be set to false so the loop did not run again,and it would continue with the orchestration.

Figure 4.8 shows a printscreen of the try/catch loop in BizTalk.

4.3.5 C# Help functions

BlacklistThe blacklisting in the BizTalk project was implemented using a help class in C#. A help classwas created, built and added to the GAC (Global Assembly Cache). A reference to the signedassembly were then later added to the BizTalk orchestration project so the functions could beused. In an expression shape the first function from the help class was called, which has anurl as input parameter. This url is the location of a text file on a blob storage, containing theblacklisted emails. The function then downloads the file locally, reads the file and stores eachaddress in a List<string>.

Later in the BizTalk orchestration where the "to" string is created by looping through the"to" tag of the object, each address is compared to the List<string> created in the first helpfunction. The function returns a bool and if it returns true the address is ignored and not putin the "to" string.

This solution works well because the only change needed when adding more addressesto be blacklisted, is the text file.Validate email address formatOnly valid emails were handled by the application. Validating an email address was per-formed by a function in the C# helper class. Each email is passed to the function where aSystem.Net.Mail.MailAddress object was constructed within a try scope. If an exception isthrown, the email address is invalid and the function returned false, otherwise true.

4.3.5.1 Deployment

Deploying a BizTalk application requires the following steps.

1. Add a strong name key file to each project in your solution (this is only done once),

2. Deploy the solution in Microsoft Visual Studio running as administrator,

3. In BizTalk Server Administrator Console, restart the host instance,

4. Refresh the application in BTS Administrator Console,

5. Configure ports if any were added since the last change,

6. If the application is not already running, start it

These steps need to be performed each and every time a change was made in the BizTalkproject. As a project is developed, this process becomes repetitive and the use of an auto-mated script doing this for you would be of great value. Not to mention, as the amount ofprojects increases. The only step that requires you to do manually is step 4 since a port shouldbe configured.

4.3.6 Local API mock

A tailor made swagger API developed by our supervisor to run on localhost was used duringthe implementation. The purpose is to emulate an API that acts like a real API used by their

30

4.3. BizTalk implementation

BizTalk applications, which you can use during development without having to burden thereal one.

This API was used in the beginning of the implementation of the scenario. A JSON objectwas constructed in BizTalk and sent to the API, and a JSON object was received from the API,containing the information about file location, file size, file name etc.

The JSON object sent to the API had the following structure:

{"items": [

{"richKey": "string","blobUIDs": [

"string"]

}]

}

Code Snippet 4.4: JSON request objectThe JSON object received from the API had the following structure:

{"items": [

{"downloadTokens": [

{"uri": "string","uid": "string","mimeType": "string","fileName": "string","fileSize": 0,"disposition": "string"

}]

}]

}

Code Snippet 4.5: JSON response objectThe JSON objects sent to the API are of the same structure as the real one used in their

applications. The response from the mock are also of the same JSON structure, but withrandomized file locations.

4.3.7 App Service

A very simple web API was created in visual studio and published to the clouds. The APIworks like the mock running on localhost explained in section 4.3.6, though this API returnsa hard coded location to a file on the blob storage. One for the email body and one for theattachments. Since this API is in the clouds, it is available from anywhere and does notrequire any software or setup for it to work, as it does with a local mock.

The API used the same JSON structure for objects received as seen in code snippet 4.4 andobjects responded as seen in code snippet 4.5.

31

4.3. BizTalk implementation

4.3.7.1 SMTP Server

For sending emails from a BizTalk orchestration, a SMTP server is required. The server usedin our application were the internal mail server which only certain IP addresses had accessto. We got help from the internal IT responsible to grant access for our machine.

32

5 Evaluation and Result

In this chapter we will perform an evaluation on the parameters described in chapter 3.

5.1 Evaluation of parameters

5.1.1 Logic Apps

5.1.1.1 P1 - Exception handling

P1 - 1 Is it possible to handle specific thrown exceptions? (As mentioned in chapter 3 theseexceptions were chosen in regard of the scenario and by request from the host company)The most basic type of exception handling in Logic Apps is the retry-policy. This policy de-fines if the action should retry if initial request timed out or failed (any request that resultedin a 429 or 5xx response). By default, all actions retry 4 additional times over 20-secondintervals. Meaning, if the first request received a 500 Internal Server Error response, theworkflow engine pauses for 20 seconds, and attempts the request again. If the response stillis an exception or failure after the retries, the workflow will continue, and mark the action as"Failed". With this it is possible to catch exception and use the runAfter property to do theappropriate action after an exception.P1 - 2 Suspend a message that could not be processedIn the implementation, when using a SB PeekLock as mentioned in 2.3.2.3, a message issuspended after it has had five (configurable amount) tries in the Logic App with a fiveminutes delay between each try. If it fails these five tries, the message is sent to the SBDeadletter-queue. From there a message needs to be examined manually and resubmitted.The retry count and interval can be altered to suit the required needs.P1 - 3 Resubmit a failed runA Logic App has an option for each run to resubmit the run as shown in figure 5.1. To re-submit when a message has been moved to the Deadletter-queue, the message can be copiedback to the regular queue and then removed from the Deadletter-queue manually.

33

5.1. Evaluation of parameters

Figure 5.1: Logic Apps Resubmit run

P1 - 4 Make sure that a message does not disappear in the SBHas the same behavior as P1 - 2 Suspend a message that could not be processed with theusage of PeekLock. A message can only be removed from the queue when the applicationcalls "complete".P1 - 5 Extracting a message from the service bus (Critical that a message does not disap-pear) Logic Apps has a built-in service bus connector for extracting messages from the queue.Another way to extract messages from the queue is to use a program called Service Bus Ex-plorer, which was used [29]. In Service Bus Explorer several operations can be used, theessential here is to examine messages that have been moved to the Deadletter-queue as wellas to move messages from the Deadletter-queue back to the normal queue. It is possible toget messages from the normal queue as well.P1 - 6 If the SMTP-server is downIf the SMTP-server is down, the send mail action will fail. I.e receive an internal server error,it will act the same as described in P1 - 1.P1 - 7 If the blob storage is downSame behavior as P1 - 6.P1 - 8 If the message is corrupt, could not be parsedIf the message is corrupt, it would cause the "Parse JSON"-action to fail. The message will besent to drift personnel for manual inspection and will be removed from the queue.

5.1.1.2 P2 - Functionality

P2 - 1 Nested loopsLogic Apps only has a for-each loop function for handling arrays, and a for-each loop in afor-each loop is not supported. It is however possible to create a “child” Logic App and send

34

5.1. Evaluation of parameters

the inner array to the child app from the parent app.P2 - 2 Adding/Altering workflowIn Logic Apps, it is not possible to add or remove an action that has a dependency. If action2 depends on action 1 and you want to move action 1, then you need to remove action 2values, move action 1 and then re-enter the values for the specific action. This proves to betime consuming when developing a logic app or changing an existing logic app.It is also not possible to add an action anywhere in the workflow. For example in a for-eachloop, if action 1 is the first action in the for-each and a new action 2 want to be the first instead.Action 2 needs to be added somewhere else where it is possible to add an action, let us sayunder action 1. Then action 1 needs to be moved under action 2 so action 2 automaticallybecomes the first action, if action 1 has dependencies the step above needs to be done.P2 - 3 VariablesLogic Apps does not support creating variables.P2 - 4 Pre-integrated connectorsLogic Apps is, as described in 2.4.1, built of connectors and these are the ones that are avail-able [15].P2 - 5 Map to other messagesLogic Apps has a rich way of handling dynamic content. Values from previous actions canbe used easily as shown in figure 5.2.

Figure 5.2: Logic Apps Map to messages

5.1.1.3 P3- Version/Source control

P3 - 1 Is it possible to use git or any other version/source control with the platform?Logic Apps can be developed in Microsoft visual studios, and with visual studios it is possibleto use git. As well as in each logic app there is a "Versions" bar under Development Toolswhich saves every time a save is done to the logic app, i.e a change. This makes it possible togo to previous versions and promote those to the the current version.

5.1.1.4 P4 - Drift

P4 - 1 What possibilities are there to monitor the application?Logic Apps saves every run with a unique ID with several properties. The individual run

35

5.1. Evaluation of parameters

contains status, duration etc and the possibility to see what every action has passed for data,which makes it easy to trace through the workflow. Logic Apps includes diagnostics to viewruns/actions/triggers that have succeeded/failed during a time span of choice. It is also pos-sible to add alert rules, such as if the application fails it will send out email to the appropriateperson.P4 - 2 How much knowledge is needed about the application(scenario) itself in order tomaintain it?We first described what the application is supposed to do, see the scenario described in 4.1.Then we explained an overview of the implemented application with the exceptions that isbeing handled. How an individual run is viewed is explained and described above. Thescenario uses the default retry policy, actions retry four additional times over 20-seconds in-tervals before the message is released back to the queue. The message will try additional fivetimes before being sent to the Deadletter-queue. To maintain the application a person needsto know two essential things.

• Know how to view a logic app run.

• Know how to view messages and resubmit a message to the SB-queue.

To view a run with statuses etc can be done using the portal by entering a run as seen infigure 5.3 and a more detailed view can be viewed seen in figure 5.4.

Figure 5.3: Logic Apps Run History

36

5.1. Evaluation of parameters

Figure 5.4: Logic Apps Detailed Run History

To view and examine messages the Service Bus Explorer is used. The messages can bemanually and individually examined and can either be removed from the Deadletter-queueor resubmitted to the SB-queue.P4 - 3 What actions are needed in case an error in the application occurredIf an error occurs the run can be viewed as mentioned above in the portal and a detaileddescription on what went wrong can be viewed. If a message is unable to finish it is sent tothe Deadletter-queue. From there the message is examined manually and if nothing seemswrong with the message it can be sent back to the SB-queue and then the Logic App run canbe viewed to see what errors have occurred. Depending on the error the appropriate responseshould be taken. E.g if it is something wrong with the application that requires a new featureor condition, it is sent to the developers to be updated.

5.1.1.5 P5 - Development/Deployment

P5 - 1 Developing an applicationThere are two different ways of developing a Logic Apps. Either by having a web-browserand entering Azure portal or by downloading Visual Studios with the necessary extensionsas described in 2.4.1.P5 - 2 Deploying an applicationWhen using the portal, the application is already deployed. All that is needed is that theLogic App is "enabled" in the overview bar.In Visual Studios, all that is needed is to right click on the project solution, deploy and addthe required Azure subscription credentials.

5.1.1.6 P6 - Business activity tracking and logging

P6 - 1 What possibilities are there to monitor the application? The company now uses AI(Application Insight) for their tracking and logging of applications. Logic Apps does nothave any pre-integrated connector to log events to AI. However it is possible to use an AzureFunction that calls and creates a log in AI. For tracing, it is possible to use the AI in the Azureportal.

5.1.1.7 P7 - Support

Does Microsoft offer any commercial support for the platform? Logic Apps does not havean individual support. However, Logic Apps is part of Azure which has support for their

37

5.1. Evaluation of parameters

products. There are five different support plans, one of which is free. These support plansgive different types of support depending on what is requested, these plans can be viewed in[23].

5.1.1.8 P8 - Community

P8 - 1 How active is the community? During the time span of the 16th January to the 24th ofMarch 2017, the total posts on stackoverflow were 67 and total posts on MSDN forum were209 [31] [20].

5.1.1.9 P9 - Continuity in development

P9 - 1 Has the product had any “major” releases in recent time or is a release announced inthe near future? Logic Apps had its first release when it was generally released 27th of July2016 [10].P9 - 2 Is the product being developed? Microsoft continuously works to improve the LogicApps platform. There are updates nearly every week, or at least each month with new fea-tures [19].

5.1.2 BizTalk

5.1.2.1 P1 - Exception handling

P1 - 1 Is it possible to handle specific thrown exceptions? (As mentioned in chapter 3 theseexceptions were chosen in regards of the scenario and by requests from the host companyYes, it is possible to handle exception types which are specific. It is also possible to handlegeneral exceptions. You can let the BizTalk orchestration throw an exception automatically,and if the exception thrown can be of various types, it is possible to catch a general exceptionin a catch scope which will catch most of the different exception types.P1 - 2 Suspend a message that could not be processedIn our implementation, each port has a retry count of 3 times with a 1 minute delay betweenthe tries. If it still fails after that, an exception is thrown and the message is being suspended.The retry count and interval can be configured in the orchestration or the application consoledepending if the port is static or dynamic.P1 - 3 Resubmit a failed runA suspended message can be examined in the BizTalk server administrator console and man-ually chosen to terminate it or to resubmit the message.P1 - 4 Make sure that a message does not disappear in the service busWhen a BizTalk application has received a message from the receive adapter, the application"owns" it. It does no longer exist in the receive location, but in the application itself whereit may be suspended. If the message fails in the receiving to the BizTalk application due toincorrect schema, the message will be suspended and can be resumed from the applicationconsole.P1 - 5 Extracting a message from the service busExtracting messages from the service bus to BizTalk is done with the SB-messaging adapter.This adapter was released in 2013 and lets the user create hybrid solutions with BizTalk as itcan send and receive messages from queues, topics and relays.P1 - 6 If the SMTP-server is downIf the SMTP server is offline, an exception will be thrown and caught in the catch scope forgeneral exceptions where it will suspend.P1 - 7 If the blob storage is downSame actions are made as if the SMTP server is offline.P1 - 8 If the message is corrupt, could not be parsedVarious events can occur if a message is corrupt. If the message is corrupted in a way that

38

5.1. Evaluation of parameters

it does not match the schema for received messages, the receive port will not be able to re-ceive the message and it will suspended automatically. However, if the message matches theschema but contains null values, it can cause errors or misbehaviour. All of them are nothandled as the amount of possible errors are too high to implement during the weeks for thebachelor thesis. These errors are however possible to handle.

5.1.2.2 P2 - Functionality

P2 - 1 Nested loopsBizTalk supports nested loops.P2 - 2 Adding / Altering workflowIt is possible to add almost any action anywhere in the orchestration. What is not possibleis the actions that would be logically wrong. For example, adding a suspend action inside aconstruction shape.P2 - 3 VariablesBizTalk supports creating and using variables.P2 - 4 Pre-integrated connectorsBizTalk has many different transport types which can be used for send and receive ports.These ports can be customized to transfer specific messages while being validated with thepipeline used for the port.P2 - 5 Map to other messagesBizTalk has a well made mapping functionality where you can move and modify values fromone schema to another dynamically. The figure 5.5 shows a screen shot of a map in BizTalk.Certain values from the source schema to the left are dragged to the destination schema tothe right. In the toolbox window, functiods are listed which can be used to modify the valuesbetween the schemas.

Figure 5.5: BizTalk Server map editor

5.1.2.3 P3 - Version/source control

P3 - 1 Is it possible to use git or any other version/source control with the platform? Sincea BizTalk application is developed in Visual Studio it is possible to set up and connect theproject to a git repository. Another possibility is to simply use a git tool and add the files

39

5.1. Evaluation of parameters

manually. By using git you can have control of which version of the project you are workingwith.

5.1.2.4 P4 - Ease-of-use (drift)

P4 - 1 What possibilities are there to monitor the application?Drifting a BizTalk application is done in the BizTalk Server Administration Console. Fromthere you can view the message that are suspended by BizTalk. The messages are groupedby application so it is possible to see which message belongs to which application. The mes-sages can be manually examined to see what the message contains and can either be resumedor terminated by the drift personal. A certain monitoring tool which is being shipped withBizTalk, called Business Activity Monitoring (BAM), can be used to monitor the application.P4 - 2 How much knowledge is needed about the application(scenario) itself in order tomaintain it?To maintain the application in BizTalk one needs to know how to resume and terminate mes-sages from the BizTalk server administration console. It can be valuable to know what struc-ture each message should have in case of pipeline errors.P4 - 3 What actions are needed in case an error in the application occur?Assuming an error occurs which causes the message to be suspended. Then a person must lo-cate the suspended message in the BizTalk Server administration console, find the suspendedmessage, determine if the message is valid or not. If the message is of wrong structure, it willnever be able to be handled by the orchestration and should be terminated. In case the mes-sage has a correct structure and is suspended due to the SMTP server is temporary offline,the message should be resumed to be able to retry to connect to the SMTP server.

5.1.2.5 P5 - Development/Deployment

P5 - 1 What software(s) is needed for developing respectively deploying an application?A BizTalk application is developed in visual studio. In visual studio you can deploy yourapplication which then will be available in the BizTalk Server administration console whichis required to handle the application.P5 - 2 What steps are required for deploying an application?For deploying the BizTalk application on your local machine, the steps needed are only touse the deploy function in visual studio, and your application will be visible in the BizTalkServer administration console.

To deploy your application to another server, a few more steps are required. In the ad-ministration console, the application must be exported to a MSI packet and moved to thelocation you wish. The packet must then be imported to the administration console of theserver moved to. It is not always that the server you deployed to has all the assemblies yourapplication references to. In that case, those assemblies must be added to the server as well.

5.1.2.6 P6 - Business activity tracking and logging

P6 - 1 What possibilities are there to monitor the application?A BizTalk application writes to the log automatically when a warning or an error occurs. It isalso possible to write to a log explicitly from the BizTalk orchestration. The logs can be viewedin the event viewer which is integrated with the BizTalk Server administration console.

As mentioned in the Logic Apps evaluation section 5.1.1.6, the company uses ApplicationInsight. It is possible to use AI with BizTalk, however it was not implemented in the scenario.

5.1.2.7 P7 - Support

P7 - 1 Does Microsoft offer any commercial support for the platform?The support for each version of BizTalk varies. Depending on the release date of the BizTalk

40

5.2. Evaluation rating

version the mainstream support is approximately 4 to 6 years. There is however an extendedsupport which is an additional 5 years, i.e. a total of 9-11 years.

5.1.2.8 P8 - Community

P8 - 1 How active is the community?The blogs and forums we personally have stumbled upon seemed to have been most activebetween 2004 to 2013 based on the date the posts were posted. There are still people askingquestions on the forums but not as frequently. When searching for an answer regarding aBizTalk problem, there are big chances it has already been answered or explained earlier on aforum or a blog.

The amount of topics about Microsoft BizTalk on stackoverflow.com is 67, and for theMSDN (Microsoft Developer Network) forum 385. Even though the amount of topics seemsmall for a product that has been released over 16 years ago, the community is still active.

5.1.2.9 P9 - Continuity in development

P9 - 1 Is the product being developed?Yes, BizTalk continues to be developed. In the latest release, BizTalk Server 2016, moreadapters were added, such as the "Logic App"-adapter. BizTalk has been developed since2000 and it is hard to say how long it will be developed. From the latest releases, you canestablish that BizTalk has adapted to other new services and products such as the Azure SBadapter released in 2013 and the Logic Apps adapter in 2016.P9 - 2 Has the product had any “major” releases in recent time or is a release announced inthe near future?Yes, BizTalk Server 2016 was the latest released version of BizTalk Server which was released1st december 2016.

5.2 Evaluation rating

Each area will be rated with respect to the definitions made in 3.1 for both BizTalk and LogicApps. The rating is described in the tables 5.1, 5.2 and 5.3 below.

41

5.2. Evaluation rating

Exception handling Logic Apps BizTalkP1-1 Is it possible to han-dle specific thrown excep-tions?

4 4

P1-2 Suspend a messagethat could not be pro-cessed

4 4

P1-3 Resubmit a failedrun

4 4

P1-4 Make sure that amessage does not disap-pear in the service bus

4 4

P1-5 Extracting a messagefrom the service bus

4 4

P1-6 If the SMTP-server isdown

4 4

P1-7 If the blob storage isdown

4 4

P1-8 If the message is cor-rupt, could not be parsed

4 4

Summation: Exceptionhandling

32 32

Table 5.1: Rated exception handling parameters

Functionality Logic Apps BizTalk

P2-1 Nested loops 3 4

P2-2 Adding / Alteringworkflow

3 4

P2-3 Variables 1 4

P2-4 Pre-integrated con-nectors/adapters

4 4

P2-5 Map to other mes-sages

4 4

Summation: Functional-ity

15 20

Table 5.2: Rated functionality parameters

42

5.2. Evaluation rating

Parameter Logic Apps BizTalkP3-1 Is it possible to useGit or any other version/-source control with theplatform?

4 4

P4-1 What possibilitiesare there to monitor theapplication?

4 4

P4-2 How much knowl-edge is needed aboutthe application(scenario)itself in order to maintainit?

4 4

P4-3 What actions areneeded in case an error inthe application occurred

4 4

P5-1 What software areneeded for developing re-spectively deploying anappli-cation?

4 4

P5-2 What steps are re-quired for deploying anapplication?

4 4

P6-1 Is it possible to logand trace events in theplatform?

4 2

P7-1 Does Microsoft offerany commercial supportfor the platform?

4 4

P8-1 How active is thecommunity?

4 4

P9-1 Is the product beingdeveloped?

4 4

P9-2 Has the product hadany “major” releases inrecent time or is a releaseannounced in the near fu-ture?

4 4

Summation: Rest of pa-rameters

44 42

Table 5.3: Rated rest of parameters

5.2.1 Evaluation summation results

Logic Apps BizTalk

Summation: Total rating 91 94

Table 5.4: Evaluation Total rating

43

5.3. Side Study

Table 5.4 shows the summation of the evaluation of the listed parameters for both LogicApps and BizTalk.

The results show that BizTalk is better than Logic Apps with regards to the evaluation,however both are even in most of the parameters and overall close. Logic Apps has somepoor functionality, whereas BizTalk has some poor default logging and event tracing utilities.

5.3 Side Study

5.3.1 Study Description

The study will test the performance on the implemented message relay scenario in LogicApps and BizTalk described in section 4.1. The performance will be tested by sending 100constructed messages containing one item, as a message should look like if they actuallywould be valid as shown in code snippet 4.1, into the SB queue. When 100 messages havearrived into the queue, the application will be activated and the test will begin. This test willbe done three times on separate days, one in the early morning, one in the mid-day and onein the afternoon.

5.3.2 Evaluation criteria

The performance will be evaluated according to the following criteria:

• the Run latency: The average time it takes for the 100 messages to finish, (i.e. when arun starts and when it ends). The run latency will only be for the application, that isfrom the moment it starts until it is finished. (The delay for the email to arrive will notbe accounted for.)

• the total time it takes for the 100 messages to arrive in the email inbox. (This includesthe delay for emails to be received)

– Number of successful runs

5.3.3 Specification

The BizTalk application was run on a 64-bit Windows Server 2012 R2 Standard machine witha 2.30 GHz Intel Xeon CPU and 4 GB RAM.

As for Logic Apps a Visual Studio Professional subscription was used with a Azure En-terprise Agreement (EA).

5.3.4 Message

A single message will contain:

• four email addresses in “to”.

• three email addresses in “cc”.

• three email addresses in "bcc".

• A text file containing blacklisted emails will be fetched from the blob storage, a size of104B.

– Four emails addresses will be blacklisted. That is, two mails in "to", one in "cc" andone in "bcc" will match an address in blacklisted emails and be removed, remainingtwo email addresses each in "to", "cc" and "bcc".

44

5.3. Side Study

• Two attachments will be fetched from the blob storage, both a .png file with the size of17.2KB.

• An html body will be fetched from blob storage, an .html file with the size of 328B.

• isBodyHtml will be true

• For the rest, "richKey", "subject", "from", "encoding", "organisationUID", it does not mat-ter what the values are, as long as they are not null.

5.3.5 Side Study Results

Table 5.5 shows the results for the study.

Performance Logic Apps BizTalkRun 1 early morningRun latency 60.86s 42sTotal time to finish 100 mes-sages

182s 50s

Number of succeeded runs 100/100 100/100Run 2 mid-dayRun latency 58.21s 44.42sTotal time to finish 100 mes-sages

175s 52s

Number of succeeded runs 100/100 100/100Run 3 afternoonRun latency 60.45s 41.73sTotal time to finish 100 mes-sages

179s 49s

Number of succeeded runs 100/100 100/100

Table 5.5: Side Study Results

5.3.6 Side study result discussion

The table 5.5 shows the results. The three runs had nearly the same time, with only a coupleof seconds as difference. It is shown that Logic Apps is much slower to deliver the emails thanBizTalk is, almost three times slower to finish all the 100 messages. That is believed to be dueto the mail server used. For BizTalk, the local mail server on the office was used meanwhileLogic Apps used Microsoft’s mail servers. Logic Apps are also slightly slower than BizTalkto handle the messages in the business process. Both platforms managed to handle all themessages without crashing or choking.

45

6 Discussion and Conclusion

In this chapter a discussion will be conducted regarding the results from the evaluation andthe side study, the method and the integration platforms Logic Apps and BizTalk. The con-clusion of the thesis and future work is also presented.

6.1 Discussion

6.1.1 Results

As we can see from the evaluation in chapter 5, the results from table 5.4 show that BizTalkis the overall better choice for an integration platform based on our criteria for evaluation.However, it is only by a small margin and Logic Apps is still equally good at most of theparameters and has some advantages over BizTalk. This shows that Logic Apps can keep upwith BizTalk.

Since Logic Apps is a cloud service, all the advantages and disadvantages given for beinga cloud service are not taken into consideration in this thesis due to time constraints, but haveto be considered when choosing the platform. Even though BizTalk is more mature in termsof the method used in this thesis, the benefits from the cloud advantages which Logic Appscan offer could prove more beneficial.

6.1.2 Method

Learning to use an integration platform takes a lot longer than the amount of time (10 weeks)we had for our thesis. From 10 weeks you got familiar with what is possible to do in eachplatform and an intuition of how things can be solved. You can of course get skillful andhave good knowledge in the platform, but we estimate the time to learn one completelyto be years. When introduced to the platforms we found out that the learning curve wascompletely different for Logic Apps and BizTalk. Logic Apps was fairly straight forwardwith not too many complications, whereas BizTalk took a lot longer.

What took time, besides learning the basics in each platform, were other parts that neededto be developed, such as the Web API. With no previous experience in any of these systems itwas fairly time consuming. As the aim of the implementation was to make it look equivalentto a real business running application, these Web API’s were developed. As for the BizTalk

46

6.1. Discussion

application, it is deployed on a server where it will be run and maintained by some driftpersonnel. But in our case it was deployed to a test server that were running in the office ofthe host company.

This thesis focused mostly on literature and if a scenario could be implemented in LogicApps. However it is not feasible to only have one scenario when comparing two platforms.The scenario in 4.1, showed that it was possible to implement the scenario in both platforms,but another scenario could prove impossible to implement in one or both platforms.

Since the cloud service is a third party provider, several concerns such as security, up-time,performance (except run latency) etc exist. None of them have been taken into considerationfor the evaluation in this thesis. However, these are aspects that need to be considered.

6.1.2.1 Selected parameters

In chapter 3, parameters were presented that were used in the evaluation. The selected pa-rameters were chosen after a literature study and a discussion between us and the host com-pany about what we thought were important to evaluate. We know that the chosen parame-ters are not enough to do a full evaluation between the platforms, but we do consider themto be key, and sufficient for the scenario.

6.1.2.2 Resources discussion

Many sources referred to in the method and implementation are from Microsoft’s documen-tation. The sources from Microsoft’s documentation regarding the platforms are trustworthyin the way that it shows what is possible to do in each platform. The Microsoft documen-tation seemed as an obvious source of information when learning about the platforms sincethey are Microsoft products. Especially regarding Logic Apps since it is new and with the ex-ception of blogs, videos etc from example BizTalk360 [1] and integration user group [5], therereally is not much else than Microsoft documentation. And just because of that, Microsoftmight seem to make the product look better than what it really is. This was taken into consid-eration. Although, the features read about in the documentation were easily confirmed whenimplementing the message relay scenario.

6.1.3 Logic Apps

Logic Apps is relatively new and is still being developed and improved continuously withupdates nearly every week. Some of these parameters that we found out to not be supportedwhen we carried out the evaluation are now supported. Our thesis was done during thetime period of 16 January - 24 March 2017. The very same date as we finished, 24 March2017, Logic Apps released an update. In the update it contained the ability to create int andfloat variables, however it was only possible to increment the variables. The same updatecontained support for nested for-each loops and the possibilities to add an action anywherein the workflow. Just from the period of time we had, many of these things were developedand are very likely to be improved and upgraded.

6.1.4 BizTalk

BizTalk is a long developed product which is stable and supports a lot of different transportprotocols and other useful features. BizTalk can be tricky in the beginning since there aremany things to consider when developing an application. But due to the product’s time onthe market, there are many tutorials and help available online.

47

6.2. Conclusion

6.2 Conclusion

In this section we will answer the research questions and some future work will be men-tioned.

6.2.1 Research Question

6.2.1.1 What aspects of the integration platforms are relevant for the host company?

Based on our discussions with our supervisor at the host company, we have concluded themost important aspects for the company when looking into an integration platform were theparameters: exception handling, source control, logging/tracing- and drift capabilities.

The evaluation in chapter 5 shows that Logic Apps and BizTalk are even in all of theseparameters except for logging/tracing were Logic Apps is rated higher than BizTalk. Weconclude that in terms of the relevant aspects for the host company, Logic Apps and BizTalkhave an even performance based on the relevant parameters which makes both platformssuitable for the company.

Another aspect that is important for the company is the pricing. However we have notevaluated that aspect, but as mentioned in 2.4 in chapter 2, Logic Apps is a product whereyou pay for what you use, and BizTalk is paid per core [13]. We are of the opinion that theLogic Apps price model could prove costly to the company when compared to BizTalk.

6.2.1.2 Is Microsoft BizTalk replaceable with Logic Apps for the host company?

From the implementation in chapter 4 and evaluation in chapter 5, BizTalk rated higher over-all in regards of the parameters by a small margin. The new Logic Apps did not get highestscore of the two platforms, however the new Logic Apps keeps up with the long developedBizTalk. We conclude that it is possible for Logic Apps to replace BizTalk.

6.2.2 Future work

As mentioned in the discussion chapter 6.1.2, several aspects have not been taken into con-sideration. Future work with comparing the advantages and disadvantages given from beinga cloud service is needed. As well as implementing several applications with different com-ponents, purposes etc would provide a broader perspective on the implementation and inte-gration capabilities. And last, evaluating other aspects, such as security, pricing, performanceetc is needed to completely determine if Logic Apps can replace BizTalk completely.

6.2.2.1 Performance - testing

Due to time and resources, a performance test to show the run latency and total time for theapplication were done three times with only 100 messages. This test shows that the sameapplication implemented in the two platforms that BizTalk runs faster. However this onlytests the performance for 100 messages, what is needed are more various tests. Such as stresstests or load tests to see how they perform/scale and to assess how these applications orother applications in general for these integration platforms operates during a longer periodof time.

48

Bibliography

[1] Biztalk360. biztalk360. URL: https : / / www . biztalk360 . com (visited on03/21/2017).

[2] Don Chambers. “Windows Azure: Using Windows Azure’s Service Bus to Solve DataSecurity Issues”. PhD thesis. Columbus State University, 2010.

[3] Michael Collier and Robin Shahan. Fundamentals of Azure. Microsoft Press, 2015.

[4] Gregor Hohpe and Bobby Woolf. Enterprise integration patterns: Designing, building, anddeploying messaging solutions. Addison-Wesley Professional, 2004.

[5] Integrationusergroup. Integrationusergroup. URL: http : / / www .integrationusergroup.com (visited on 03/21/2017).

[6] Sladana Jankovic, Snežana Mladenovic, Vesna Radonjic, Aleksandra Kostic-Ljubisavljevic, and Ana Uzelac. “Integration Platform-As-A-Service In e Traffic SafetyArea”. In: MIC-CNIT2011, Mosharaka International Conference on Communications, Net-working and Information Technology, Dubai, UAE. 2011, pp. 70–75.

[7] mattchenderson. An introduction to Azure Functions. URL: https : / / docs .microsoft.com/en-us/azure/azure-functions/functions-overview(visited on 03/21/2017).

[8] Peter Mell, Tim Grance, et al. “The NIST definition of cloud computing”. In: (2011).

[9] Microsoft. Adapters in BizTalk Server. URL: https://msdn.microsoft.com/en-us/library/aa561360.aspx (visited on 03/22/2017).

[10] Microsoft. Announcing Azure Logic Apps general availability. URL: https://azure.microsoft.com/en-us/blog/announcing-azure-logic-apps-general-availability/ (visited on 03/22/2017).

[11] Microsoft. Azure Products. URL: https : / / azure . microsoft . com / en - us /services/?&sort=popular&filter=all (visited on 03/21/2017).

[12] Microsoft. Azure-regions. URL: https://azure.microsoft.com/en-us/regions(visited on 03/21/2017).

[13] Microsoft. BizTalk pricing. URL: https://www.microsoft.com/en-us/cloud-platform/biztalk-pricing (visited on 03/21/2017).

49

Bibliography

[14] Microsoft. Blob storage documentation. URL: https://opbuildstorageprod.blob.core.windows.net/output-pdf-files/en-us/Azure.azure-documents/live/storage.pdf (visited on 03/22/2017).

[15] Microsoft. Connectors list. URL: https://docs.microsoft.com/en-us/azure/connectors/apis-list (visited on 03/21/2017).

[16] Microsoft. Design, build, and deploy Azure Logic Apps in Visual Studio. URL: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-deploy-from-vs (visited on 03/21/2017).

[17] Microsoft. Installation Overview for BizTalk Server 2013 and 2013 R2. URL: https :/ / msdn . microsoft . com / en - us / library / jj248688 . aspx (visited on01/16/2017).

[18] Microsoft. Logic Apps documentation. URL: https://opbuildstorageprod.blob.core.windows.net/output-pdf-files/en-us/Azure.azure-documents/live/logic-apps.pdf (visited on 03/21/2017).

[19] Microsoft. logicappsupdates. URL: https : / / blogs . msdn . microsoft . com /logicappsupdate/ (visited on 03/21/2017).

[20] Microsoft. MSDN Forum Logic Apps. URL: https://social.msdn.microsoft.com/forums/en-us/home?forum=azurelogicapps (visited on 03/21/2017).

[21] Microsoft. Pipelines. URL: https://msdn.microsoft.com/en-us/library/aa560864.aspx (visited on 03/22/2017).

[22] Microsoft. Service bus documentation. URL: https://opbuildstorageprod.blob.core.windows.net/output-pdf-files/en-us/Azure.azure-documents/live/service-bus-messaging.pdf (visited on 03/21/2017).

[23] Microsoft. supportlogicapps. URL: https : / / azure . microsoft . com / en - us /support/plans/ (visited on 03/21/2017).

[24] Microsoft. System.Net.Mail Namespace. URL: https://msdn.microsoft.com/en-us/library/system.net.mail(v=vs.110).aspx (visited on 03/21/2017).

[25] Microsoft. What’s New in BizTalk Server 2013 and 2013 R2. URL: https : / / msdn .microsoft.com/en-us/library/jj248703.aspx (visited on 03/22/2017).

[26] Martin Potocnik and Matjaz B Juric. “Integration of saas using ipaas”. In: The 1st Inter-national Conference on CLoud Assisted ServiceS. 2012, p. 35.

[27] Ling Qian, Zhiguo Luo, Yujian Du, and Leitao Guo. “Cloud computing: An overview”.In: IEEE International Conference on Cloud Computing. Springer. 2009, pp. 626–631.

[28] Alex Rodriguez. “Restful web services: The basics”. In: IBM developerWorks (2008).

[29] Paolo Salvatori. Service Bus Explorer 2.6 now available! URL: https://blogs.msdn.microsoft.com/paolos/2015/03/02/service-bus-explorer-2-6-now-available/ (visited on 03/21/2017).

[30] Stackoverflow. Stackoverflow Biztalk. URL: https : / / stackoverflow . com /questions/tagged/biztalk (visited on 03/21/2017).

[31] Stackoverflow. Stackoverflow Logic Apps. URL: https : / / stackoverflow . com /questions/tagged/azure-logic-apps (visited on 03/21/2017).

[32] Swagger. Swagger. URL: http://swagger.io (visited on 03/21/2017).

[33] Mitch Tulloch. Introducing Windows Azure for IT Professionals. Microsoft Press, 2013.

[34] w3schools.com. JSON - Introduction. URL: https://www.w3schools.com/js/js_json_intro.asp (visited on 03/21/2017).

[35] Qi Zhang, Lu Cheng, and Raouf Boutaba. “Cloud computing: state-of-the-art and re-search challenges”. In: Journal of internet services and applications 1.1 (2010), pp. 7–18.

50