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
Linköpings universitet SE–581 83 Linköping +46 13 28 10 00 , www.liu.se Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år frå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 enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att 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 i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt 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 eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida 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 to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot 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 measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni- versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Anton Berglund Oscar Fredriksson Abstract
Integration has always been an important and tricky task for IT-businesses. There are several products available for solving integration issues, one of them is the long developed platform BizTalk from Microsoft. As cloud computing has grown in recent years, Microsoft has been putting more focus towards the cloud. With their cloud, named Azure, expanding a 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 the purpose of finding out if the new Logic Apps can replace the long developed BizTalk. The evaluation is performed by implementing an application in both platforms, then evaluat- ing selected parameters by giving each a score to concretize our assessment on quantify whether Logic Apps can replace BizTalk. Contents
Abstract iii
Acknowledgments iv
Contents iv
List of Figures vi
List of Tables 1
1 Introduction 2 1.1 Introduction ...... 2 1.2 Background ...... 2 1.3 Aim...... 3 1.4 Research questions ...... 3 1.5 Approach ...... 3 1.6 Thesis Structure ...... 3
2 Theory 4 2.1 Integration ...... 4 2.2 Cloud computing ...... 6 2.3 Azure ...... 8 2.4 Logic Apps ...... 11 2.5 BizTalk ...... 13 2.6 Miscellaneous ...... 17
3 Method 18 3.1 Choice of the parameters ...... 18 3.2 Defined parameters ...... 19 3.3 Evaluation ...... 20
4 Implementation 21 4.1 Message Relay Scenario ...... 21 4.2 Logic Apps implementation ...... 24 4.3 BizTalk implementation ...... 28
5 Evaluation and Result 33 5.1 Evaluation of parameters ...... 33 5.2 Evaluation rating ...... 41 5.3 Side Study ...... 44
6 Discussion and Conclusion 46 6.1 Discussion ...... 46 6.2 Conclusion ...... 48
iv Bibliography 49 List of Figures
2.1 Many to many connections ...... 5 2.2 One to many connections ...... 5 2.3 Cloud Service Models ...... 6 2.4 Azure Function development in Azure portal ...... 9 2.5 Logic Apps Components ...... 12 2.6 BizTalk components overview ...... 13 2.7 BizTalk orchestration overview ...... 16
4.1 Message-relay overview ...... 22 4.2 Message-relay operations ...... 22 4.3 Logic Apps Parent workflow ...... 25 4.4 Logic Apps Child workflow 1 ...... 25 4.5 Logic Apps Child workflow 2 ...... 26 4.6 Logic Apps Child workflow 3 ...... 26 4.7 Logic Apps Child workflow 4 ...... 27 4.8 Try-Catch scope in BizTalk ...... 29
5.1 Logic Apps Resubmit run ...... 34 5.2 Logic Apps Map to messages ...... 35 5.3 Logic Apps Run History ...... 36 5.4 Logic Apps Detailed Run History ...... 37 5.5 BizTalk Server map editor ...... 39
vi List of Tables
3.1 Rating definitions ...... 20
5.1 Rated exception handling parameters ...... 42 5.2 Rated functionality parameters ...... 42 5.3 Rated rest of parameters ...... 43 5.4 Evaluation Total rating ...... 43 5.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 applications developed that exchange information needs to be integrated in the system. To integrate these systems, engineers often use software called integration platforms. In recent years cloud computing has grown bigger. With cloud computing, many services has appeared, such as the Software-as-a-Service (SaaS), where a user can use a software which is not installed on user machines. Using cloud services has many benefits compared to using software installed locally (on-premise). On-premise software is often more expensive and requires more configuration and maintenance which can be time consuming. As new cloud integration platforms emerge, they might be more beneficial for solving integration problems. Several companies are considering to migrate to the cloud. However, as the new cloud services are being released, it is interesting to see how these new kind of software can replace the 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 the world. With employees developing systems on different locations, the systems need to be integrated. 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 is mainly working with development and integration. Microsoft BizTalk is the current platform used to solve integration issues. The platform is stable, and has been developed since its release in year 2000. However, as cloud computing is growing, there may have appeared other solutions to solve integration problems. One of the solutions could be the newly released Microsoft Logic Apps 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 them by 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 and BizTalk. Chapter 4 contains the scenario description and the implementation in Logic Apps and BizTalk. Chapter 5 contains the evaluation of the parameters described in the method as well as a side study done to test the performance of implemented applications. Chapter 6 contains 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 Logic Apps, Azure Function, Blob storage and Service Bus. Lastly the integration platform BizTalk is 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 integration solution 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 support personnel can immediately answer if items are in store or sold out. All these systems that trade information require a connection between each other. Now imagine an organization with over thousands of different systems that trade information with each other. Since every system needs a single connection to the other systems, the number of connections is going to exceed the number of systems, see figure 2.1. This can be problematic when troubleshooting errors due to the amount of connections. Adding and/or removing existing systems would not 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 integration hub, or platform whose purpose is to connect all the other systems. In other words, instead of all systems being connected to each other, all "small" systems are only connected to the integration platform whereas the integration platform is connected to all the systems as in figure 2.2. With an integration platform the amount of connections are reduced and the ability to 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 integration platforms, 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 the Internet instead of having to store the data on your own devices. Several definitions of the word 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 and Technology) 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 the resources should be easy to scale up or down for the consumer based on the consumers current 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 user does 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, operating system, storage or the application capabilities. A SaaS service can be accessed from various devices through a program interface or directly through the web without the need to install a 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 create applications 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 "software life 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 without caring about the underlying infrastructure. The difference between SaaS and PaaS is that SaaS only 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 physical servers but can instead purchase the IaaS infrastructure and thus easily regulate the amount they 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. One of them is the integration Platform as a Service(iPaaS). Similar to PaaS, iPaaS offers a cloud platform 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 develop integration flows that enable connectivity to SaaS and other applications in the cloud. The user 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 single organization 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 confidential data 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 by a 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, the cloud infrastructure is open to the general public for the consumers to use according to the service provider’s policy. It is located on the premises of the cloud provider. An example of those 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. cloud bursting for load-balancing between clouds) [8] [35].
2.3 Azure
Microsoft Azure, previously known as Windows Azure, is a cloud computing platform and infrastructure 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 services can be accessed through the Azure web portal, and most of services have also been integrated in 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 hands of the user. This is not always entirely positive. With an expanding organization this forces enterprises to develop their own private data centers and that is usually both time-consuming and hard to scale. In addition, the enterprise has to weigh of being able to expand to meet future needs on one hand and not purchasing too much hardware on the other hand (since that will most likely not be an efficient way of handling the companie’s money). Another downside with having to establish several small computer centers is that they are not as energy efficient as having one large computer center [35] [27]. Azure handles all these problems, all hardware is provided by Microsoft and the user only pays for what services they procured, and that obviously makes it easier to scale the required capacity up or down from one time to another. Another benefit with Azure is that the user can easily change between software/OS etc without the need to install the software on their hardware [3]. Despite the benefits of cost and easy scaling, Azure still has some general flaws which is general to all cloud computing services. Since all hardware is hosted and located on another companies premise, the user has no control over it. For some companies that aspect is a security concern. All companies hold some data they consider confidential and by cloud computing 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 important and critical parts or data are located on the local machines. This ensures the security and privacy of a company’s data by keeping it under the company’s control whilst at the same time making it more reliable to its customers [3]. Since it is a hybrid solution, a connection is needed between Azure and an on-premise data center. To solve this Azure developed Azure Service Bus. The on-premise data center is connected to the cloud by using the Service Bus and the data can be accessed [3]. The Azure Service 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 broken down into four categories; compute, network, data and app services. Since 2013 there has been such an increase that four categories do not suffice anymore. As of 4 march 2017, there are 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, Logic Apps 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 integrate it with your solution. With Azure Functions it is only needed to write the code to solve the problem at hand and there is no need to worry about the infrastructure or the application that will run it. It currently supports several code languages, such as C#, F#, Node.js, Python and PP. Azure Functions can be either coded and tested in the Azure portal as shown in figure 2.4 or 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, which is accessed with the HTTP or HTTPS protocol. The stored data can be public for anyone to access it or store the data privately. The blob storage can be used for a variety of things such as: [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 and Blob [14].
• Store account - A storage account is used for accessing the Azure Storage. There are two different 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 is specialized 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 in a container. A blob storage account can have an unlimited number of containers, and a container 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 of blobs:
– Block blobs - A block blob can contain up to 50,000 blocks of up to 100 MB each for a total size of approximately 4.75 TB. Block Blobs are often used for storing text or binary files. – Append blobs - Append blobs are also made up of blocks like block blobs, but append 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 total size around 195 GB. – Page Blob - A Page blob is more efficient than a block- or append blob for frequent read/write operations. A Page blob can be up to 1 TB in size which makes Azure Virtual 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 (exchanging information) over the cloud. The service bus works as a postal service in the real world, when two or more parties want to exchange information the service bus works as a middleman receiving and delivering the message to its intended recipient. The purpose of the service bus is to make communication easier and asynchronous where both parties do not need to be connected 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 a broker) that stores messages in the queue until they are received. Each message can only be received once by a single recipient. Topics - Provides a one-way communication using subscriptions. Same as a queue, a topic acts as a broker, but each subscription can use a filter to only receive messages that match a specific criteria. A topic is able to have multiple subscriptions. Relays - Provides a bi-directional subscription. However, unlike queues and topics, it is not a broker 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 be explained further.
The queue uses the FIFO (first-in-first-out) principle to relay their messages. This means that messages are expected to be received and processed by the receivers in the order that they were added to the queue, and each message can only be received and processed by one recipient. 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 has finished processing the message, the message will be lost. It is a simple procedure, but it has been removed from the queue so no other receiver can access it. This is however solved with PeekLock. PeekLock reads a message from the queue but it does not delete it. Instead it puts a lock on the message, receiving a lock-id and making it invisible for other receivers and wait for 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 the lock-id and the message is deleted from the queue.
• If the receiver cannot successfully process the message, it calls Abandon(). The queue then 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 of time (default set to 60 seconds), the queue assumes that the receiver has failed. It then behaves as the receiver had called Abandon(), which as mentioned above makes the message 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 much literature 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. By being 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 and easy 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 to implement 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 with integration support.
2.4.1 Developing a Logic App Developing a Logic App can be done by either using the Azure portal or Microsoft Visual Studios. For the Azure portal all that is needed is a web browser, whilst Visual Studios require the 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 process that orchestrates integrations between various parts. Building a Logic Apps consist mainly of 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 are essentially called an "action", but for the purpose of explaining, we have chosen to separate these components [18].
11 2.4. Logic Apps
Figure 2.5: Logic Apps Components
Workflow A workflow is the whole logic app application, the process from start to finish. That is from a triggered event until all inserted parts in the logic app have finished running. Each logic app defines a workflow, the minimum requirements are to have at least one trigger, then followed by one or more actions and optionally flow controls [18].
Trigger A trigger is an event that starts the logic apps workflow based on a specific event. A trigger can start the workflow without passing any parameters, or have an initial message associated to it. There are two ways of initiating a run of the logic app, by either a polling or a pushing trigger [18].
Connector The 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 its own API and require some information to be configured in order to connect to the specific service. For example the Outlook-connector, all that is needed for the developer to have an outlook 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].
Action An action executes one step in the logic apps workflow after the triggered event. An action is typically a connector or a flow control in the workflow [18].
Flow Control The flow control allows the user to control the flow of execution of the workflow. That is using the data from a trigger or previous action and analyzing it. Logic Apps have four types of 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 connect various systems together. It was first released year 2000, making it a well documented and stable platform. Unlike Logic Apps, BizTalk is an on-premise software, meaning it must be installed 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 communicating with 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 to enable all kinds of communication. The other part is called an orchestration which allows you to create and run graphically-defined processes. There are several other technologies that are a part of the engine: A Business Rules Engine which allows evaluating complex sets of rules. A Health and Activity Tracking tool which allows administrators and developers to monitor and manage the engine and orchestration it runs. An Enterprise Single Sign-On facility, which provides the ability to map authentication information between Windows and non-Windows systems. A Business Activity Monitoring, which allows information workers to monitor a running business process. The information being 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, which allows 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 it to a receive pipeline. Here the message gets decoded, validated, depending on the pipeline’s configuration. The message then gets placed in a MessageBox database. From the Message box, the message can be passed to the orchestration if the orchestration subscribes to the types of messages, where it gets processed and passed back to the Message Box. The message then goes through a send pipeline where it can get encoded, assembled, and then lastly, to a send adapter.
2.5.4 BizTalk Server Administration Console The BizTalk Server Administration Console is a program from where the user can configure a BizTalk application. Here the user can also view events that have been logged, suspended and terminated messages, see an overview of the amount of critical errors and warnings that has occurred. Suspended messages can be resumed or terminated from here and the suspended messages can be grouped by application, enabling the user to know which message belongs to 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 and started from BizTalk Server Administration Console in order to run. Applications can also be refreshed 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 to from 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 use different data protocols, and the adapters thus enable the systems to communicate with each other [9]. When a message is passed to the adapter, it writes meta data to the message, such as what endpoint 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 is possible to create your own adapter, to solve specific problems with the BizTalk Adapter Framework. There is a vast amount of third-party adapters, such as the Gmail BizTalk Adapter, which can be downloaded and used. Adapters can be configured and modified in the BizTalk Server Administration Console to your own preferences. As for BizTalk Server 2013 R2, a Service-Bus adapter has been added, which lets the user to send and receive messages to a Microsoft Azure Service Bus [25]. This makes it possible for 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". Receive pipelines handle a message after it has been handled by a receive adapter, and the send pipeline handle a message before going out to a send adapter. A pipeline has a set of stages it goes through, and since receive pipelines and send pipelines work differently, they have different 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 to the validate stage of a receive pipeline. The said component can be configured to validate a message against a specific schema, or the pipeline will not process the message and be suspended. Another example could be to add a JSON encoder component to the encoding stage in the send pipelines, so the XML message converts to a JSON message before going through 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 to business processes who subscribe to certain messages.
2.5.8 Schema All messages processed in BizTalk are based on the XML Schema definition language, and are referred to as a schema. Schemas can be used to validate structure of a message received to BizTalk. Schemas can be created manually or with a wizard. By using the wizard, it is possible to enter a JSON message as input and the wizard will construct a schema based on that. It can also be done with a flat file. Since all documents handled by BizTalk are XML, all schemas need to be transformed to XML before they can be processed. This is not necessary if the schema is a so called XML schema, which is one of four types of schemas that exist. The remaining types of schemas that need transformation before being processed are flat file schemas, envelope schemas and property schemas
2.5.9 Maps In BizTalk, a map is used to transform data from one document to another. A map is defined in the BizTalk Mapper of a BizTalk project. Transformation between a source document and a target document can be as simple as copying the values to the other, or more complex using so called functoids to perform more complex transformations. A functoid can be described as 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 the configured 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, where it 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 like to see how the business process is going can monitor how the application behaves. A B2B process can take days, weeks or even longer, so watching the process can be relevant for the businesses 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 orchestration you 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 be dragged 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 modified to specific behaviours. Messages are passed from the message box to an orchestration if they match a subscription an orchestration has. When an orchestration has processed a message, the message is sent back 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 editor variables 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 help class is a C# file which BizTalk can use by adding a reference to the assembly of the help class. 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 its parameter list.
16 2.6. Miscellaneous
2.6 Miscellaneous
This section contains further background areas of which are important to the theory as they are 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 web browser. In the simplest terms a Web API enables applications to communicate with each other by using the same language. Since its over the web, the communication is defined as a structure set of HTTP request and HTTP response messages, which is usually in the form of the universal XML or JSON format.
2.6.1.1 REST/RESTful API REST (REpresentational State Transfer) defines a set of architectural principles for designing web services. REST sends a URI to transfer messages between applications using universal HTTP protocol. Because of this, in recent years REST Web services have become predominant as 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 the parameters, context and data needed within the HTTP headers and body for the server to generate a response.
• The interaction between the client and resource in the server should be done by sending URIs only.
• A REST API should support JSON and/or XML as the format for exchanging data in the 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 viewed in any web browser, from which it being automatically generated from any API defined in the specification [32].
17 3 Method
In this chapter the method is presented with the parameters that are being used to evaluate Logic 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 parameters will be evaluated.
3.1 Choice of the parameters
We propose to evaluate Logic Apps and BizTalk by comparing different parameters. These parameters 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 in Logic Apps and BizTalk in order to evaluate the platforms. The scenario and implementation will be described in chapter 4. The parameters listed below are what we believe are essential areas in integration solutions which are important to consider when choosing an integration platform.
• 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 defined them, 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 chapter 4. These exceptions were chosen in regards of the scenario and by requests from the host company. Other exceptions exist, but these are the ones that are important for the scenario.
– 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 not disappear) – 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 required steps for handling an error. ∗ P4 - 2 How much knowledge is needed about the application(scenario) itself in 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 started 16/1-2017 to 24/3-2017 we have looked at how many posts have been posted on MSDN 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 show the 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
Platform has none-to-little support/documentation for the parameter, 2 some difficult workarounds, tailor made solutions or time consuming solutions are needed Platform has some support/documentation for the parameter, some 3 easy 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 BizTalk and 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 the cloud. With this approach they are currently developing a new platform in the cloud for their services, applications etc. Handling notifications about the services, applications etc. in any format is a part of this platform, however since it is being developed, email is one of the first steps of notification handling. Implementing a typical application in both Logic Apps and BizTalk for the company, will help us evaluating the parameters described in chapter 3. The evaluation of the parameters made 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 beyond the scope of the study, we do not care what happens before the message have entered the 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 necessary to know what happens before a message is received to the queue. All that is needed to know is 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 arrows describe 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 format The 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 used to map to the specific file from the blob storage. This is being handled by an API, which also is 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 and BizTalk, both will be explained in the respective implementation sections. "BCC" is only handled in the Logic Apps implementation. BCC is not handled by the SMTP adapter 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 being used by other applications before they reach this application and these might be added later on 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 Logic Apps, and how they were implemented. The subsections do not appear in the same order as the application were implemented in. The development of the Logic App was done using the Azure Portal with the Mozilla Firefox browser.
4.2.1 Workflow The parent workflow The 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 because it 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, it completes the message and removes it from the SB-queue. The child workflow The child workflow takes in one item and does the operations as mentioned in figure 4.2 with some 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. Blacklist The Blacklist-function takes in the "to", "cc", "bcc" arrays and the "blacklistedemails" array fetched 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 0 with a delimiter ";" after each address. Validate email address format The outlook-action requires that an address contains a valid email format. To solve this the .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 Logic App 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 .NET framework. The API receives a JSON object containing richKey and blobUID as shown below 4.2. The API responds with a message format containing information shown below 4.3. Since this API only mimic the behavior it does not have the same functionality, i.e mapping the richKey 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 Apps For 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 of the 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 BizTalk and how they were implemented. The subsections do not appear in the same order as the application 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 up which we used. This saved us a lot of time. Instead of having to install and configure the required software from scratch, we only downloaded and installed Oracle VM VirtualBox Manager 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 your own log events to the log. This is however considered as bad practice since it fills the log with unspecific event id’s, but easy to implement, and was done a few times when troubleshooting the application.
4.3.3 SB-Messaging Adapter The Service Bus (SB-Messaging) adapter is used to receive messages from the service bus entities (Queues, Topics or Relays). SB-Messaging adapter can be used to bridge connectivity between Microsoft Azure and on-premise BizTalk servers, which allows users to create hybrid applications. This adapter was used to receive the JSON message to BizTalk. A Microsoft Azure Service Bus queue was created in the Azure Portal, where the JSON messages going to the BizTalk application could be stored and received from. For BizTalk to be able to receive messages from the queue the queue must be without partitioning. This option can be configured when creating 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 throws an exception in case an error has occurred, and the catch scope which follows the scope catches it. Every catch scope in our implementation is catching General Exceptions, this is because of two reasons:
1. By catching a general exception, the user does not get an exception object on which the user can perform actions on, as he/she would get if they were to catch a specific exceptions. Since we do not know how we would handle the exception object, there was no reason for 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 catch them all. If we catch an exception, the message will be suspended and it can then be examined 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 implemented using a bool variable and a loop which would loop until the communication succeeded. If an exception 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 suspend the message. If it then later were resumed, the loop variable would be set to true so the loop would run again and retry the communication. If the loop variable was true, meaning no exception 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 Blacklist The blacklisting in the BizTalk project was implemented using a help class in C#. A help class was created, built and added to the GAC (Global Assembly Cache). A reference to the signed assembly were then later added to the BizTalk orchestration project so the functions could be used. In an expression shape the first function from the help class was called, which has an url as input parameter. This url is the location of a text file on a blob storage, containing the blacklisted emails. The function then downloads the file locally, reads the file and stores each address in a List
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 BizTalk project. 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 of projects increases. The only step that requires you to do manually is step 4 since a port should be configured.
4.3.6 Local API mock A tailor made swagger API developed by our supervisor to run on localhost was used during the 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 the real one. This API was used in the beginning of the implementation of the scenario. A JSON object was 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 object The 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 object The 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 with randomized file locations.
4.3.7 App Service A very simple web API was created in visual studio and published to the clouds. The API works like the mock running on localhost explained in section 4.3.6, though this API returns a hard coded location to a file on the blob storage. One for the email body and one for the attachments. Since this API is in the clouds, it is available from anywhere and does not require 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 and objects 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 used in our application were the internal mail server which only certain IP addresses had access to. 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 these exceptions 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 resulted in a 429 or 5xx response). By default, all actions retry 4 additional times over 20-second intervals. Meaning, if the first request received a 500 Internal Server Error response, the workflow engine pauses for 20 seconds, and attempts the request again. If the response still is 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 the appropriate action after an exception. P1 - 2 Suspend a message that could not be processed In the implementation, when using a SB PeekLock as mentioned in 2.3.2.3, a message is suspended after it has had five (configurable amount) tries in the Logic App with a five minutes delay between each try. If it fails these five tries, the message is sent to the SB Deadletter-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 run A 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 copied back 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 SB Has the same behavior as P1 - 2 Suspend a message that could not be processed with the usage of PeekLock. A message can only be removed from the queue when the application calls "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, the essential here is to examine messages that have been moved to the Deadletter-queue as well as to move messages from the Deadletter-queue back to the normal queue. It is possible to get messages from the normal queue as well. P1 - 6 If the SMTP-server is down If 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 down Same behavior as P1 - 6. P1 - 8 If the message is corrupt, could not be parsed If the message is corrupt, it would cause the "Parse JSON"-action to fail. The message will be sent to drift personnel for manual inspection and will be removed from the queue.
5.1.1.2 P2 - Functionality P2 - 1 Nested loops Logic Apps only has a for-each loop function for handling arrays, and a for-each loop in a for-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 workflow In Logic Apps, it is not possible to add or remove an action that has a dependency. If action 2 depends on action 1 and you want to move action 1, then you need to remove action 2 values, move action 1 and then re-enter the values for the specific action. This proves to be time 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-each loop, 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 say under action 1. Then action 1 needs to be moved under action 2 so action 2 automatically becomes the first action, if action 1 has dependencies the step above needs to be done. P2 - 3 Variables Logic Apps does not support creating variables. P2 - 4 Pre-integrated connectors Logic 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 messages Logic Apps has a rich way of handling dynamic content. Values from previous actions can be 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 possible to use git. As well as in each logic app there is a "Versions" bar under Development Tools which saves every time a save is done to the logic app, i.e a change. This makes it possible to go 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 view runs/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 appropriate person. P4 - 2 How much knowledge is needed about the application(scenario) itself in order to maintain 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 is being handled. How an individual run is viewed is explained and described above. The scenario 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 five times before being sent to the Deadletter-queue. To maintain the application a person needs to 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 in figure 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 be manually and individually examined and can either be removed from the Deadletter-queue or resubmitted to the SB-queue. P4 - 3 What actions are needed in case an error in the application occurred If an error occurs the run can be viewed as mentioned above in the portal and a detailed description on what went wrong can be viewed. If a message is unable to finish it is sent to the Deadletter-queue. From there the message is examined manually and if nothing seems wrong with the message it can be sent back to the SB-queue and then the Logic App run can be viewed to see what errors have occurred. Depending on the error the appropriate response should be taken. E.g if it is something wrong with the application that requires a new feature or condition, it is sent to the developers to be updated.
5.1.1.5 P5 - Development/Deployment P5 - 1 Developing an application There are two different ways of developing a Logic Apps. Either by having a web-browser and entering Azure portal or by downloading Visual Studios with the necessary extensions as described in 2.4.1. P5 - 2 Deploying an application When using the portal, the application is already deployed. All that is needed is that the Logic App is "enabled" in the overview bar. In Visual Studios, all that is needed is to right click on the project solution, deploy and add the 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 not have any pre-integrated connector to log events to AI. However it is possible to use an Azure Function that calls and creates a log in AI. For tracing, it is possible to use the AI in the Azure portal.
5.1.1.7 P7 - Support Does Microsoft offer any commercial support for the platform? Logic Apps does not have an 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 plans give 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 of March 2017, the total posts on stackoverflow were 67 and total posts on MSDN forum were 209 [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 in the near future? Logic Apps had its first release when it was generally released 27th of July 2016 [10]. P9 - 2 Is the product being developed? Microsoft continuously works to improve the Logic Apps 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 these exceptions were chosen in regards of the scenario and by requests from the host company Yes, it is possible to handle exception types which are specific. It is also possible to handle general 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 exception in a catch scope which will catch most of the different exception types. P1 - 2 Suspend a message that could not be processed In our implementation, each port has a retry count of 3 times with a 1 minute delay between the 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 console depending if the port is static or dynamic. P1 - 3 Resubmit a failed run A 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 bus When 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 where it may be suspended. If the message fails in the receiving to the BizTalk application due to incorrect schema, the message will be suspended and can be resumed from the application console. P1 - 5 Extracting a message from the service bus Extracting 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 it can send and receive messages from queues, topics and relays. P1 - 6 If the SMTP-server is down If the SMTP server is offline, an exception will be thrown and caught in the catch scope for general exceptions where it will suspend. P1 - 7 If the blob storage is down Same actions are made as if the SMTP server is offline. P1 - 8 If the message is corrupt, could not be parsed Various 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 the schema but contains null values, it can cause errors or misbehaviour. All of them are not handled as the amount of possible errors are too high to implement during the weeks for the bachelor thesis. These errors are however possible to handle.
5.1.2.2 P2 - Functionality P2 - 1 Nested loops BizTalk supports nested loops. P2 - 2 Adding / Altering workflow It is possible to add almost any action anywhere in the orchestration. What is not possible is the actions that would be logically wrong. For example, adding a suspend action inside a construction shape. P2 - 3 Variables BizTalk supports creating and using variables. P2 - 4 Pre-integrated connectors BizTalk 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 the pipeline used for the port. P2 - 5 Map to other messages BizTalk has a well made mapping functionality where you can move and modify values from one 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 to the right. In the toolbox window, functiods are listed which can be used to modify the values between 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? Since a BizTalk application is developed in Visual Studio it is possible to set up and connect the project 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 working with.
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. From there you can view the message that are suspended by BizTalk. The messages are grouped by 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 resumed or terminated by the drift personal. A certain monitoring tool which is being shipped with BizTalk, 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 to maintain 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 suspended message, determine if the message is valid or not. If the message is of wrong structure, it will never 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 your application which then will be available in the BizTalk Server administration console which is 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 to use the deploy function in visual studio, and your application will be visible in the BizTalk Server 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 the location you wish. The packet must then be imported to the administration console of the server moved to. It is not always that the server you deployed to has all the assemblies your application 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 is also possible to write to a log explicitly from the BizTalk orchestration. The logs can be viewed in 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 Application Insight. 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 extended support 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 active between 2004 to 2013 based on the date the posts were posted. There are still people asking questions on the forums but not as frequently. When searching for an answer regarding a BizTalk problem, there are big chances it has already been answered or explained earlier on a forum or a blog. The amount of topics about Microsoft BizTalk on stackoverflow.com is 67, and for the MSDN (Microsoft Developer Network) forum 385. Even though the amount of topics seem small 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, more adapters were added, such as the "Logic App"-adapter. BizTalk has been developed since 2000 and it is hard to say how long it will be developed. From the latest releases, you can establish that BizTalk has adapted to other new services and products such as the Azure SB adapter 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 in the near future? Yes, BizTalk Server 2016 was the latest released version of BizTalk Server which was released 1st december 2016.
5.2 Evaluation rating
Each area will be rated with respect to the definitions made in 3.1 for both BizTalk and Logic Apps. The rating is described in the tables 5.1, 5.2 and 5.3 below.
41 5.2. Evaluation rating
Exception handling Logic Apps BizTalk P1-1 Is it possible to han- dle specific thrown excep- 4 4 tions? P1-2 Suspend a message that could not be pro- 4 4 cessed
P1-3 Resubmit a failed 4 4 run P1-4 Make sure that a message does not disap- 4 4 pear in the service bus
P1-5 Extracting a message 4 4 from the service bus
P1-6 If the SMTP-server is 4 4 down
P1-7 If the blob storage is 4 4 down
P1-8 If the message is cor- 4 4 rupt, could not be parsed
Summation: Exception 32 32 handling
Table 5.1: Rated exception handling parameters
Functionality Logic Apps BizTalk
P2-1 Nested loops 3 4
P2-2 Adding / Altering 3 4 workflow
P2-3 Variables 1 4
P2-4 Pre-integrated con- 4 4 nectors/adapters
P2-5 Map to other mes- 4 4 sages
Summation: Functional- 15 20 ity
Table 5.2: Rated functionality parameters
42 5.2. Evaluation rating
Parameter Logic Apps BizTalk P3-1 Is it possible to use Git or any other version/- 4 4 source control with the platform? P4-1 What possibilities are there to monitor the 4 4 application? P4-2 How much knowl- edge is needed about the application(scenario) 4 4 itself in order to maintain it? P4-3 What actions are needed in case an error in 4 4 the application occurred P5-1 What software are needed for developing re- 4 4 spectively deploying an appli-cation? P5-2 What steps are re- quired for deploying an 4 4 application? P6-1 Is it possible to log and trace events in the 4 2 platform? P7-1 Does Microsoft offer any commercial support 4 4 for the platform?
P8-1 How active is the 4 4 community?
P9-1 Is the product being 4 4 developed? P9-2 Has the product had any “major” releases in recent time or is a release 4 4 announced in the near fu- ture?
Summation: Rest of pa- 44 42 rameters
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 Logic Apps 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 some poor 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 Logic Apps and BizTalk described in section 4.1. The performance will be tested by sending 100 constructed messages containing one item, as a message should look like if they actually would be valid as shown in code snippet 4.1, into the SB queue. When 100 messages have arrived into the queue, the application will be activated and the test will begin. This test will be done three times on separate days, one in the early morning, one in the mid-day and one in 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 a run starts and when it ends). The run latency will only be for the application, that is from the moment it starts until it is finished. (The delay for the email to arrive will not be accounted for.)
• the total time it takes for the 100 messages to arrive in the email inbox. (This includes the 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 with a 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 of 104B.
– Four emails addresses will be blacklisted. That is, two mails in "to", one in "cc" and one in "bcc" will match an address in blacklisted emails and be removed, remaining two 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 of 17.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 BizTalk Run 1 early morning Run latency 60.86s 42s Total time to finish 100 mes- 182s 50s sages Number of succeeded runs 100/100 100/100 Run 2 mid-day Run latency 58.21s 44.42s Total time to finish 100 mes- 175s 52s sages Number of succeeded runs 100/100 100/100 Run 3 afternoon Run latency 60.45s 41.73s Total time to finish 100 mes- 179s 49s sages 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 couple of seconds as difference. It is shown that Logic Apps is much slower to deliver the emails than BizTalk is, almost three times slower to finish all the 100 messages. That is believed to be due to the mail server used. For BizTalk, the local mail server on the office was used meanwhile Logic Apps used Microsoft’s mail servers. Logic Apps are also slightly slower than BizTalk to handle the messages in the business process. Both platforms managed to handle all the messages without crashing or choking.
45 6 Discussion and Conclusion
In this chapter a discussion will be conducted regarding the results from the evaluation and the 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 BizTalk is 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 the parameters and has some advantages over BizTalk. This shows that Logic Apps can keep up with BizTalk. Since Logic Apps is a cloud service, all the advantages and disadvantages given for being a cloud service are not taken into consideration in this thesis due to time constraints, but have to be considered when choosing the platform. Even though BizTalk is more mature in terms of the method used in this thesis, the benefits from the cloud advantages which Logic Apps can 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 each platform and an intuition of how things can be solved. You can of course get skillful and have good knowledge in the platform, but we estimate the time to learn one completely to be years. When introduced to the platforms we found out that the learning curve was completely different for Logic Apps and BizTalk. Logic Apps was fairly straight forward with not too many complications, whereas BizTalk took a lot longer. What took time, besides learning the basics in each platform, were other parts that needed to be developed, such as the Web API. With no previous experience in any of these systems it was fairly time consuming. As the aim of the implementation was to make it look equivalent to 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 drift personnel. But in our case it was deployed to a test server that were running in the office of the host company. This thesis focused mostly on literature and if a scenario could be implemented in Logic Apps. 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 consideration for 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 them to 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 trustworthy in 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 since they 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], there really is not much else than Microsoft documentation. And just because of that, Microsoft might 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 when implementing the message relay scenario.
6.1.3 Logic Apps Logic Apps is relatively new and is still being developed and improved continuously with updates nearly every week. Some of these parameters that we found out to not be supported when we carried out the evaluation are now supported. Our thesis was done during the time period of 16 January - 24 March 2017. The very same date as we finished, 24 March 2017, Logic Apps released an update. In the update it contained the ability to create int and float variables, however it was only possible to increment the variables. The same update contained support for nested for-each loops and the possibilities to add an action anywhere in the workflow. Just from the period of time we had, many of these things were developed and 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 transport protocols and other useful features. BizTalk can be tricky in the beginning since there are many things to consider when developing an application. But due to the product’s time on the 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 the most important aspects for the company when looking into an integration platform were the parameters: 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 these parameters except for logging/tracing were Logic Apps is rated higher than BizTalk. We conclude that in terms of the relevant aspects for the host company, Logic Apps and BizTalk have an even performance based on the relevant parameters which makes both platforms suitable for the company. Another aspect that is important for the company is the pricing. However we have not evaluated that aspect, but as mentioned in 2.4 in chapter 2, Logic Apps is a product where you pay for what you use, and BizTalk is paid per core [13]. We are of the opinion that the Logic 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 highest score of the two platforms, however the new Logic Apps keeps up with the long developed BizTalk. 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 being a 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, performance etc 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 the application were done three times with only 100 messages. This test shows that the same application implemented in the two platforms that BizTalk runs faster. However this only tests the performance for 100 messages, what is needed are more various tests. Such as stress tests or load tests to see how they perform/scale and to assess how these applications or other applications in general for these integration platforms operates during a longer period of time.
48 Bibliography
[1] Biztalk360. biztalk360. URL: https : / / www . biztalk360 . com (visited on 03/21/2017). [2] Don Chambers. “Windows Azure: Using Windows Azure’s Service Bus to Solve Data Security 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, and deploying messaging solutions. Addison-Wesley Professional, 2004. [5] Integrationusergroup. Integrationusergroup. URL: http : / / www . integrationusergroup.com (visited on 03/21/2017). [6] Sladana¯ Jankovi´c, Snežana Mladenovi´c, Vesna Radonji´c, Aleksandra Kosti´c- Ljubisavljevi´c,and Ana Uzelac. “Integration Platform-As-A-Service In e Traffic Safety Area”. 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 on 01/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 Potoˇcnikand 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