Linköpings universitet SE–581 83 Linköping
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
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 givevaluat-ing 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 . . . 183.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
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
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
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.
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 parameChap-ter 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.
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 supsup-port 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].
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].
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., netnet-works, 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].
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 hardsoft-ware or middlesoft-ware [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-on-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].
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].
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
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 ReceiveAndReceiveAnd-Delete 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]
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].
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].
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 Busibusi-ness Activity Services, which allows information workers to set up and manage interactions with trading partners.
2.5.3
How does BizTalk work?
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
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.
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.
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].
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
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
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
2
Platform has none-to-little support/documentation for the parameter, some difficult workarounds, tailor made solutions or time consuming solutions are needed
3
Platform has some support/documentation for the parameter, some easy workarounds, tailor made solutions or small time consuming so-lutions are needed
4 Platform has full support/documentation for the parameter
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.
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:
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": "sendermail@gmail.com",
"subject": "This is the subject for the email",
"bodyBlobUID": "123227668", "to": [ "example@gmail.com", "2ndexample@gmail.com" ], "cc": [ "example@hotmail.com" ], "bcc": [ "example@yahoo.com" ], "encoding": "System.Text.UTF8Encoding", "isBodyHtml": true, "organisationUID": "00000000-0000-0000-0000", "attachmentBlobUIDs": ["123227668"] } }] }
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.
4.2. Logic Apps implementation
Figure 4.3: Logic Apps Parent workflow
4.2. Logic Apps implementation
Figure 4.5: Logic Apps Child workflow 2
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" }
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.
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
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<string>.
Later in the BizTalk orchestration where the "to" string is created by looping through the "to" tag of the object, each address is compared to the List<string> created in the first help function. The function returns a bool and if it returns true the address is ignored and not put in the "to" string.
This solution works well because the only change needed when adding more addresses to be blacklisted, is the text file.
Validate email address format
Only valid emails were handled by the application. Validating an email address was per-formed by a function in the C# helper class. Each email is passed to the function where a System.Net.Mail.MailAddress object was constructed within a try scope. If an exception is thrown, the email address is invalid and the function returned false, otherwise true.
4.3.5.1 Deployment
Deploying a BizTalk application requires the following steps.
1. Add a strong name key file to each project in your solution (this is only done once), 2. Deploy the solution in Microsoft Visual Studio running as administrator,
3. In BizTalk Server Administrator Console, restart the host instance, 4. Refresh the application in BTS Administrator Console,
5. Configure ports if any were added since the last change, 6. If the application is not already running, start it
These steps need to be performed each and every time a change was made in the 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
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.
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.
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.
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
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?
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.
