Guaranteed Delivery

Guaranteed delivery (GD) uses log stores to ensure that a GD subscriber registered with a GD window receives all the data processed by that window even if the client is not connected when the data is produced.

GD is supported only on windows assigned to log stores. For streams, delta streams, or windows assigned to memory stores, consider using persistent subscribe pattern (PSP). For information on PSP, see the Studio Users Guide.

When you enable guaranteed delivery on a window that has registered guaranteed delivery subscribers, the window stores a copy of every event it produces in its log store until all the registered guaranteed delivery subscribers acknowledge receiving the events.

Note: The window stores copies of events only if there are registered guaranteed delivery subscribers.

SAP recommends that when you enable guaranteed delivery and set up subscriptions, you also enable the consistent recovery option in the project configuration (CCR file).

You can set up a GD window in Studio or directly in the CCL file using a CREATE WINDOW or CREATE FLEX statement. Make sure to assign a log store to each GD-enabled window. Do not create GD-enabled windows inside modules—this is not supported because you cannot attach adapters or subscribe directly to elements in modules.

A window configured for GD also supports non-GD subscriptions. Enabling GD does not significantly affect the window’s performance when it has no registered GD subscribers.

You can subscribe to windows configured for GD using adapters, bindings, the SDKs, or the subscribe tool.

Adapters

Enable guaranteed delivery on the adapters that support it and configure the GD adapter parameters. See the Adapters Guide for information on adapter support for GD.

Bindings

Enable GD on any project bindings to ensure that data is delivered to remote projects. See the Studio Users Guide for details.

SDKs

In the SDKs, set up GD subscriptions so each client can receive data and checkpoint messages from your project. The client, in turn, must periodically respond to the project server with a commit message reporting the sequence number of the latest event the client has processed. The server does not need to save events once it knows that all GD clients have processed them, so it can free up their space for other uses.

See the C SDK Guide, the Java SDK Guide, and the .NET SDK Guide for more information.

Subscribe Tool

For testing or simple use cases, use the esp_subscribe tool to subscribe in GD mode. See the Utilities Guide for details.

Recommendations for Guaranteed Delivery Subscribers

Follow these recommendations to reduce your chances of receiving duplicate rows or inconsistent data after subscriber or server restart.

Make sure the project you subscribe to is running in consistent recovery mode. See the Studio Users Guide or the Configuration and Administration Guide for details on setting project deployment options for consistent recovery.
Subscribe to a window on which GD is enabled. You can identify GD-enabled windows:
- Using the supports_gd command in the esp_client utility (see the Utilities Guide for more information)
- Using commands in the SDKs (see the C SDK Guide, the Java SDK Guide, and the .NET SDK Guide for more information)
- Using the _ESP_Streams metadata window—look for streams that have a nonzero entry in the supports_gd column (see the Configuration and Administration Guide for more information)
Send data on to your client as it arrives or buffer it locally. Issue commits for only those messages for which you have received a checkpoint notification. If the client does not support commits, deliver only those messages that have been checkpointed by the server and cache the rest locally. This ensures that the client is always consistent with the server on a restart after a client or server failure.
To minimize data loss, SAP recommends that you do one of the following:
- Configure the publisher to issue commits frequently (see the C SDK Guide, the Java SDK Guide, and the .NET SDK Guide for more information).
- Configure the Auto Checkpoint project deployment option to control how frequently the client receives checkpoint messages (see the Studio Users Guide or the Configuration and Administration Guide for details on setting project deployment options for consistent recovery.)
When the ESP server sends a checkpoint message, send a commit to the client or send the buffered rows followed by a commit.
Issue a GD commit with the last committed sequence number to ensure that the server does not send the data again the next time the server or the subscription restarts. Note, however, that if the server does not shut down cleanly, it resends committed events that were not checkpointed.