Technical Guide Reference Guide Frequently Asked Questions Tutorials
Show menu

Flow Proxy - Examples

Reliable / Unreliable property setting

One of the properties you can set is the Reliable property. But what does it mean?

When you set the reliable property in the flow proxy to true, you make the message reliable only for receiving the message. This means that if the flow proxy is, for whatever reason (agent down, or something else), not available, the message will be kept in a Message Queue on the server and when the flow proxy is available again, the message will be delivered from the queue.

The difference between a reliable proxy and an unreliable proxy is that a reliable proxy message will be kept on disk in a queue, while an unreliable proxy message is kept in a queue in memory. If your ConnectAgent is down because of a power down or something like that, the reliable proxy can be retrieve the message from the saved queue on disk, while the unreliable proxy cannot. The message is gone because the memory was cleared.

Example

Requirements

  • You can download the interface here.
  • You need a license for ConnectPlaza Control

Unzip the file and install the interface by creating a new Business Connector with the name Demo-ReliableFlowTestInterface (for example) and import the interface via the Create new interface window.

 

Select the Demo-ReliableFlowTestInterface.cadapter file and press Save to upload the file into the system. 

Business connector / Interface and Flows

How it works

We drop a file into the file pickup directory. This file will be send via the message copy to the reliableFlow and to the unreliableFlow. Both the reliableFlow and the unreliableFlow have by default the property on the consumer, autostart consumer, set to false. Therefore the message send to the reliableFlow will be written to the queue and saved to disk. The message send to the unreliableFlow will be kept in a queue in memory.

The Flow Proxy (both) will look something like this:

Now we start Control and open the ConnectAgent, the interface and the flow. You will see something like this:

You see that the consumer is not started.

First example

  • Put a file into the ./temp/inputReliable directory, this file will trigger the events
  • Now we select the and select the menu-option Turn on. This will consume the message and drop it into the directory ./temp/reliableout.
  • The same thing you do with the unreliableFLow, turn on the consumer and a message will be delivered into your ./temp/unreliableout directory.
  • Turn both consumers off now.

You seen that both message will be delivered as planned.

Second example

  • Put a file into the ./temp/inputReliable directory, this file will trigger the events
  • Stop your connectAgent (via Windows services or via the Linux command service connectAgentUpdater stop

What happens is that the message is consumed with the FilePickup component and distributed via the message-copy component to the reliableFlow and the unreliableFlow as described previous. Now we have stopped the ConnectAgent, the memory is flushed, which means that the memory where the message of the unreliableFlow has stored the message, is also flushed. The message is gone. But the message sent to the reliableFlow stays on disk in its queue. So this message is saved.

When we startup the agent and turn on both consumers via Control, the expected behaviour is that the message send to the reliableFlow will be dropped in the directory /temp/reliableout. As for the message send to the unreliableFlow, this message is gone, therefor no message will be dropped in the directory /temp/unreliableout

  • Start your connectAgent (when agent is down) via your Windows services of via the Linux command: service connectAgentUpdater start
  • Turn on the reliableFlow consumer. A message will be dropped into the directory /temp/reliableout. This is expected.
  • Now turn on the unreliableFlow consumer. No message will be dropped into the directory /temp/unreliableout. The message was lost, as expected.