Figure 1.
Kourier Integrator Online Help
This guide describes the Kourier services architecture which consists of messaging, processing, and scheduling information that provide a wide variety of integration capabilities. Each service manages the exchange of information between any application that provides or consumes data.
When executing a service, Kourier leverages a powerful messaging subsystem to perform the transfer of data between applications. For more information on how Kourier performs the messaging, refer to the Kourier Messaging Guide. You can also create services that use Kourier's powerful import and export features. This not only allows you to send your U2 information to another application, but you can also be confident that imported data is valid, even if you have customized your software. And by using Kourier's flexible scheduling capabilities, you can control when these services run.
The general flow of Kourier Services is to process messages. One or more messages are generated by a source application. Kourier retrieves these messages from a source DSN and processes them. Any resulting messages are then passed on to a target DSN. The general flow of a service is shown in Figure 1.
Figure 1.
It is not necessary to specify all of the components of a service. If a service is only going to be run on an as-needed basis does not need to have a schedule. Also, services can omit any one of the Source DSN, Commands, or Target DSN fields. These types of services are used to:
process source DSN messages
move messages from source DSN to a target DSN
move created messages to a target DSN
These scenarios are described more fully in the sections that follow.
In this scenario, messages created by a third party application are retrieved by Kourier and processed by commands on the U2 server. Messages generated by the commands that process the inbound messages are simply dropped, or the commands may not generate messages at all. An example of this type of service is the KS_IMPORT service, which is used to import messages from KommerceServer. A diagram is shown in Figure 2.
Figure 2.
In this scenario, there is no command to process incoming or outgoing messages. Kourier acts as a message router, retrieving messages from a source DSN and moving them to a target DSN. An example of this type of service is shown in Figure 3.
Figure 3.
In this scenario, there is no source DSN. Messages are created as a result of processing commands in the service. These messages are then sent on to the target DSN. An example of this is a KS_EXPORT_FULL, which creates dozens of datasets that get exported to KommerceServer. An example of this type of service is shown in Figure 4.
Figure 4.
By providing a Kourier Schedule for your services, you control when your integration runs. Services can be scheduled based on the day or days of the week, your company's fiscal calendar, or choose one or more days of a year, even years out.
You can specify the frequency with which services execute down to the second. Plus you can specify a window in which the service runs. This lets you run services more frequently during your peek operation hours, and maybe only once or twice on the weekend.
Kourier services have advanced features that allow you to simplify the administration of your integrations, and make them more modular.
When integrating with complex applications, you frequently have many services that access messages in the similar locations. For example, different services may retrieve all their messages from the same FTP server but in different directories. Or, they may even retrieve them from the same directory but with different filenames. In situations like these where most of the DSN information is identical and only the directories or filenames change between services, you can use append addresses to minimize maintenance. For more information on how to use append addresses, refer to the Kourier DSN Guide.
Kourier may occasionally be unable to send an outgoing message to a target DSN. This can happen when a network is down or when a server is off-line. This can result in an undeliverable message in a queue. For each service, you can control whether or not undeliverable messages are left in the queue or if they are simply dropped.
The command stack allows you to specify more than one Kourier command to process messages. Kourier uses the internal SYSTEM queue to ensure that the messages are process properly, even if a service aborted on a prior run.
In the example shown in Figure 5, the service has two Kourier commands. Each message retrieved from the source DSN is processed by the first command in the command stack. This command generates messages that are then processed by the second command in the stack. The output of the second command is then sent to the target DSN.
Figure 5.