Persistent Line Dispatcher

Synchronous communication is used for real time data exchange between an external system and Autoline. The external system places a synchronous request at the StarConnect data server which will forward this request to the Autoline server. This requires a connection between the StarConnect data server and the Autoline server. This connection, called a persistent line, is established by the Autoline server and remains open during the day in order that STCDS can use this line to place the request at the Autoline server.

Requests retrieved over the persistent line need processing immediately and the response is send back to STCDS. The response is not sent over the persistent line as this handles only the communication from STCDS to Autoline. The asynchronous communication channel is used to send back the information to the data server. These requests are handled by the request processor. It is possible to run multiple request processors per persistent line to avoid that the requests received from STCDS are waiting until the request processor is available.

The synchronous communication requires therefore three processes within Autoline:

(Green square two arrows downwards) Persistent line dispatcher: The persistent line dispatcher is the main controlling process for the synchronous communication and performs the following tasks:
- Starts and stops the persistent line handlers and processors
- Monitors the status of the persistent line handlers and processors and restarts them if they are not running or responding
- Allocates incoming requests that are received by the persistent line handler to an available processor
- Purges processed records for the synchronous inbound queue
Requests received from STCDS will contain an Operation ID. Every process that uses STCDS has a unique operation ID and is used by the line dispatcher to determine the processor module that handles the request. The Processing Modules form displays the configured operation ID's for a specific module. The dispatcher allocates a request to the first free processor that is running for the corresponding module based on the operation ID.
Persistent line handler: The persistent line handler establishes the persistent line connection between Autoline and STCDS and start listening on the line until the STCDS send data to Autoline.

STCDS sends on regular basis keep live messages to Autoline to avoid that the line is disconnected if it is idle for a long time. These messages are in principle ignored by the persistent line handler, but the connection is reinitiated if no keep live messages are received in the last 12 minutes.

Requests that are received from STCDS are stored in the inbound queue for synchronous communication (MB.MS.scdsi file) and the persistent line handler informs the dispatcher about the new request that is received.

Note: The persistent line process uses one KCML user license to provide support on the background processes. You might need an increase of the available user licenses when activating the persistent line in Autoline.
Request processor: The request processor is generating the response on the received request and sends it back to STCDS over the asynchronous communication line.

The persistent line dispatcher starts automatically additional processor modules when the available processors are occupied. The request is allocated to the newly started processer. This makes parallel handling of requests, with a maximum of three request processors for the same type, possible.

The persistent line dispatcher informs the request processor to handle a received request that is stored by the persistent line handler in the inbound queue for synchronous communication. The status of the inbound queue is set to Processed once the request processor has sent back the response and the request processor will report back to the persistent line dispatcher that it is available to handle a new request.

The dispatcher, persistent line handlers and the processors are running as different processes on the Autoline server. The communication between these processes is done via a Global object. The global object is a shared memory segment which holds the status of the different processes. The Persistent Line Dispatcher form displays the contents of this global object.

The Persistent Line Dispatcher form handles the main controlling process for the synchronous communication. You can monitor the status of the persistent lines and the processors.

Persistent Line Dispatcher Form

This form is displayed when you click Manufacturer-specific > MB. Mercedes-Benz > Menu - Utilities > StarConnect Data Server > Persistent Line Dispatcher. It handles the main controlling process for the synchronous communication.

Menu Bar and Toolbar:

Menu bar	Toolbar	Action
File > Exit		Returns you to the previous menu.

Tools > Start dispatcher	-	Starts the dispatcher process and also the persistent line handlers plus processors. This option is only available if the dispatcher is not running. Tip: You can setup the Dispatcher function to start and stop the daemons automatically in Timed operations with module MS and option MBMDSSCP (Persistent line dispatcher). You can also use the Start All Backgrounds function manually or automatically in Timed operations with module SU and option STARTALL (Start all backgrounds), so that the Mercedes-Benz Daemon Monitor is triggered to start all concerning Mercedes-Benz daemons.
Tools > Stop dispatcher	-	Stops the dispatcher process and also the persistent line handlers plus processors. This option is only available if the dispatcher is running. Tip: You can setup the Dispatcher function to start and stop the daemons automatically in Timed operations with module MS and option MBMDSSCP (Persistent line dispatcher). You can also use the Start All Backgrounds function manually or automatically in Timed operations with module SU and option STARTALL (Start all backgrounds), so that the Mercedes-Benz Daemon Monitor is triggered to start all concerning Mercedes-Benz daemons.
Tools > Show logfile	—	Displays the log that is generated by the persistent line processes.
Tools > View processed requests	—	Displays the contents of the inbound queue for synchronous communication.

Help > Help		Displays this help topic in a web browser.
Help > About	—	Displays version and copyright information.

Persistent Line Handlers Grid:

Displays the details of the configured processes and their status.

External system ID: Displays the GSSN dealer number of the main outlet of the dealer (retailer). The Line handler and Processers are grouped per retailer, their descriptions are available in this field below the retailer number. The description of the processor is from the processing module.

Note: The first data gridline (below the headers) displays the details of the persistent line dispatcher.

Partition: Displays the partition number (unique ID allocated by KCML) of the process.

Status: Displays the status of the dispatcher, line handler or processor which is kept in the global object and validated by the dispatcher on regular basis:

Dispatcher: The first gridline (below the headers) displays the status of the persistent line dispatcher.

Not running: The dispatcher is not running, causing that the persistent line handlers and the processors will stop running as well.

Running: This is the normal operating status indicating that the dispatcher is running correctly.

Requested to stop: This is a temporary status to inform that the dispatcher is requested to stop running.

Line handler: Displays the status of the persistent line handler. There is only one line handler per retailer.

Not running: The persistent line handler is not running.

Launching...: The dispatcher indicated that the persistent line handler is not running and launches the line handler process.

Not connected: The persistent line handler process is running but the persistent line is not connected to the STCDS.

Connecting...: The persistent line handler is trying to establish a connection for the persistent line with the dispatcher.

Waiting for incoming requests: The persistent line is connected and available for retrieving requests from the dispatcher.

Processing request: A request is received, the line handler stores the request in the inbound queue and informs the dispatcher about the new request received.

Connection timed out: STCDS sends every 12 minutes a keep live message. The connection will time out if the keep live message is not received, the line handler automatically tries to reconnect the line.

Connection error: The persistent line handler failed to connect to STCDS. The system automatically reconnects in 10 minutes time and tries this for maximum 5 times. A manual intervention is needed to establish the connection after trying 5 times.
Tip: An email is sent to the user specified in the System manager email of the StarConnect Data Server Parameters on the first connection error and this system manager is also informed by mail if the line is again connected.

Requested to stop: This is a temporary status that the persistent line process needs to stop. The persistent line handler disconnects the persistent line and stops the process.

Processor: Displays the status of the processer. Each processor is running for a specific processing module.

Not running: The processor is not running.

Launching...: The dispatcher indicated that the processor is not running and launches the processor.

Initiating...: The processor is started and is initiating the necessary environment.

Available: The processor is running and available to process a request.

Request allocated: The dispatcher has allocated a request to this processor.

Processing request...: The processor is processing the request allocated.

Processor error: The processor indicated an error during initialization.

Unable to load module: This error is displayed when the processor was not able to load the corresponding module, hence the processor is unavailable.

Requested to stop: This is a temporary status that the processor needs to stop. The processor will stop running.

Note: In case of the retailer number it displays the description of the retailer.

Requests: Displays the total number of requests for:

Line handler: Displays the total number of requests that are stored in the inbound queue of this persistent line. This does not include the keep live messages. Records from the inbound queue are automatically purged after 7 days.

Processor: Displays the total number of requests that the processor has processed since it was started.

Last access: Displays the time in HH:MM:SS format:

Line handler: Displays the time since the last request is sent by the STCDS. The time is reset when receiving a keep live message. The connection is terminated and reestablished in case the time exceeds 12 minutes.

Processor: Displays the time since the last process the processor has executed.

Outstanding Synchronous Request Grid:

Displays the requests that are received on the persistent line, which are not processed yet.

External System ID: Displays the GSSN dealer number of the main outlet of the dealer (retailer) which has received the request.

ID: Displays an unique ID in the inbound queue for synchronous transfer.

Request ID: Displays the unique Request ID received from STCDS. This request ID is included in the response to STCDS.

Type: Displays the type of the request as configured by STCDS.

Operation: Displays the ID of the operation provided by STCDS. The operation ID is used to determine the processing module that handles the request.

Status: Displays the status of the request:

New: New request received that is not yet allocated to a processor.

Assigned: The request is assigned to a processor.

Processed: The processor has returned a response to the data server.

Error: The processor was not able to process the request.

Processor: Displays the ID of the processor that is allocated to process this request. For example, 1 is the first processor in the list of this external system ID.