The below diagram shows the architecture of BizTalk360. 


BizTalk360_Architecture


The four main components of the BizTalk360 architecture are:

  1. BizTalk360 Web Interface
  2. REST API Layer (JSON)
  3. BizTalk360 Monitoring Service
  4. BizTalk360 Database


1. BizTalk360 Web Interface

This is the user facing end of the architecture. BizTalk360 is a HTML5/JavaScript based Single Page Application (SPA) primarily designed for biztalk monitoring and supporting Microsoft BizTalk Server environments. Any communications between the web interface and the BizTalk server environment will take place through the REST API Layer. For instance, when operations like starting the host instance, viewing the status of the application and so on are performed from the web interface, the request and response are sent through the REST API Layer directly between the web interface and server environment.


2. REST API Layer (JSON)

This is the transport mode between the web interface and the server environment to collect any information.


3. BizTalk360 Monitoring Service

The BizTalk360 Monitoring Service is a separate Windows NT Service. The responsibility of the monitoring service is to pick up the configuration information from the BizTalk360 database (that is saved by the user from the web interface) and perform the checks in the BizTalk server environment. It is also responsible to send the notifications through the channels specified by the user and storing the state information in the BizTalk360 database, if required.


4. BizTalk360 Database

The BizTalk360 database mainly contains the configuration information such as number of BizTalk server environments, security information (like User Access Policy), monitoring information based on the configuration that is the set by the user in BizTalk360 application and so on. In general, the BizTalk360 database stores the Meta data information. For e.g., when the user requests the state of the receive location, only the state information is stored in the BizTalk360 database because it is the expected state that we are storing. In case of operational activities (like retrieving the state of host instances and so on), BizTalk360 does not persist any of the environment information in BizTalk360 Database and the information is directly rendered in the web interface.


Key characteristics of BizTalk360 architecture

The following are the key characteristics of BizTalk360 architecture,


1. Agentless architecture

In practice, most of the monitoring solutions require an agent to be installed in the BizTalk server environment. The agent is responsible to collect the information from the environment and store it in a centralized database. BizTalk360 does not require any agent to be installed in the server environment. We have made our architecture so simple that you can simply install BizTalk360 on a separate server and point it to the BizTalk environment.


The service account under which the Monitoring Service and the IIS Application Pool is running should have the necessary permissions to access the remote BizTalk server environment.


2. Centralized monitoring solution

With a single installation of BizTalk360, it is possible to configure multiple environments without installing any agents.


3. Scalability

One of the drawbacks of having a central monitoring solution is the lack of ability to scale after certain extent. For instance, it is not practical to set up 20 environments with a single installation of BizTalk360 and ask the BizTalk360 Monitoring service to monitor all the 20 environments. With BizTalk360, we perform scaling at the "environment level". You can set up multiple installations of BizTalk360 for a specific purpose like Production, QA, and so on. So instead of having 20 environments in a single installation of BizTalk360, you can have 5 installations (instances) of BizTalk360 and configure every instance to have few environments.


biztalk360 workflow diagram