Monitor mixed transports with ServiceControl adapter

This sample shows how to configure ServiceControl to monitor endpoints and retry messages when using mixed transports. The endpoint in this solution uses the SQL Server transport while ServiceControl runs on the learning transport. The same approach can be used to connect a single service control instance to multiple instances of the same message broker e.g. multiple databases used for SQL Server transport.

Prerequisites

Ensure an instance of SQL Server (Version 2016 or above for custom saga finders sample, or Version 2012 or above for other samples) is installed and accessible on localhost and port 1433. A Docker image can be used to accomplish this by running docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=yourStrong(!)Password' -p 1433:1433 -d mcr.microsoft.com/mssql/server:latest in a terminal.

Alternatively, change the connection string to point to different SQL Server instance.

At startup each endpoint will create its required SQL assets including databases, tables, and schemas.

Running the project

Start the Adapter, Endpoint and PlatformLauncher projects.
ServiceControl should open automatically in the default browser.
Go to the Endpoint console and press o to send a message.
Notice the endpoint receives its own message and successfully processes it.
Press f to simulate message processing failure.
Press o in to create more messages.
Notice this time messages fail to be processed.
Go to ServicePulse and select the Failed Messages view.
Notice the existence of one failed message group with two messages. Open the group.
Press f in the Endpoint console to disable the failure simulation.
Press the "Retry all" button in ServicePulse.
Go to the Endpoint console and verify that the message has been successfully processed.
Shut down the Endpoint.
Open ServicePulse and notice a red label next to the heart icon. Click on that icon to open the Endpoints Overview. Notice that the Endpoint is now displayed in the Inactive Endpoints tab.

Code walk-through

The code base consists of three projects.

Endpoint

The Endpoint project contains an endpoint that simulates the execution of a business process by sending a message to itself. It includes a message processing failure simulation mode (toggled by pressing f) which can be used to generate failed messages for demonstrating message retry functionality. It uses the SQL Server transport.

The Endpoint has the heartbeats plugin installed to enable uptime monitoring via ServicePulse.

Adapter

The Adapter project hosts the ServiceControl.TransportAdapter. The adapter has two sides: endpoint-facing and ServiceControl-facing. In this sample the endpoint-facing side uses SQL Server transport and the ServiceControl-facing side uses the Learning transport:

Copy code|Copy usings|Edit

var transportAdapterConfig = new TransportAdapterConfig<SqlServerTransport, LearningTransport>("Samples.ServiceControl.Adapter");

The following code configures the adapter to use SQL Server transport when communicating with the business endpoints.

Copy code|Copy usings|Edit

transportAdapterConfig.CustomizeEndpointTransport(
    customization: transport =>
    {              
        // for SqlExpress use Data Source=.\SqlExpress;Initial Catalog=transport_adapter;Integrated Security=True;Encrypt=false;Max Pool Size=100;Min Pool Size=10
        var connectionString = @"Server=localhost,1433;Initial Catalog=transport_adapter;User Id=SA;Password=yourStrong(!)Password;Encrypt=false;Max Pool Size=100;Min Pool Size=10";

        transport.ConnectionString(connectionString);
    });

Duplicates

ServiceControl Transport Adapter might introduce duplicates in the message flow when adapting two transports that cannot be configured to participate in an atomic transaction.