Class ProcessingModule

Results and waiting options are depends on the wait parameter. All returned results will be removed from the queue's resolved list.

Results and waiting options are depends on the wait parameter. All returned results will be removed from the queue's resolved list.

NOTE: Available only for lib-node binding.

Message monitor performs background monitoring for a message processing results for the specified set of messages.

Message monitor can serve several isolated monitoring queues. Each monitor queue has a unique application defined identifier (or name) used to separate several queue's.

There are two important lists inside of the monitoring queue:

• unresolved messages: contains messages requested by the application for monitoring and not yet resolved;

• resolved results: contains resolved processing results for monitored messages.

Each monitoring queue tracks own unresolved and resolved lists. Application can add more messages to the monitoring queue at any time.

Message monitor accumulates resolved results. Application should fetch this results with fetchNextMonitorResults function.

When both unresolved and resolved lists becomes empty, monitor stops any background activity and frees all allocated internal memory.

If monitoring queue with specified name already exists then messages will be added to the unresolved list.

If monitoring queue with specified name does not exist then monitoring queue will be created with specified unresolved messages.

Message monitor performs background monitoring for a message processing results for the specified set of messages.

Message monitor can serve several isolated monitoring queues. Each monitor queue has a unique application defined identifier (or name) used to separate several queue's.

There are two important lists inside of the monitoring queue:

• unresolved messages: contains messages requested by the application for monitoring and not yet resolved;

• resolved results: contains resolved processing results for monitored messages.

Each monitoring queue tracks own unresolved and resolved lists. Application can add more messages to the monitoring queue at any time.

Message monitor accumulates resolved results. Application should fetch this results with fetchNextMonitorResults function.

When both unresolved and resolved lists becomes empty, monitor stops any background activity and frees all allocated internal memory.

If monitoring queue with specified name already exists then messages will be added to the unresolved list.

If monitoring queue with specified name does not exist then monitoring queue will be created with specified unresolved messages.

NOTE: Available only for lib-node binding.

Creates ABI-compatible message, sends it to the network and monitors for the result transaction. Decodes the output messages' bodies.

If contract's ABI includes "expire" header, then SDK implements retries in case of unsuccessful message delivery within the expiration timeout: SDK recreates the message, sends it and processes it again.

The intermediate events, such as WillFetchFirstBlock, WillSend, DidSend, WillFetchNextBlock, etc - are switched on/off by send_events flag and logged into the supplied callback function.

The retry configuration parameters are defined in the client's NetworkConfig and AbiConfig.

If contract's ABI does not include "expire" header then, if no transaction is found within the network timeout (see config parameter ), exits with error.

Creates ABI-compatible message, sends it to the network and monitors for the result transaction. Decodes the output messages' bodies.

If contract's ABI includes "expire" header, then SDK implements retries in case of unsuccessful message delivery within the expiration timeout: SDK recreates the message, sends it and processes it again.

The intermediate events, such as WillFetchFirstBlock, WillSend, DidSend, WillFetchNextBlock, etc - are switched on/off by send_events flag and logged into the supplied callback function.

The retry configuration parameters are defined in the client's NetworkConfig and AbiConfig.

If contract's ABI does not include "expire" header then, if no transaction is found within the network timeout (see config parameter ), exits with error.

NOTE: Available only for lib-node binding.

Sends message to the network and returns the last generated shard block of the destination account before the message was sent. It will be required later for message processing.

Sends message to the network and returns the last generated shard block of the destination account before the message was sent. It will be required later for message processing.

NOTE: Available only for lib-node binding.

send_events enables intermediate events, such as WillFetchNextBlock, FetchNextBlockFailed that may be useful for logging of new shard blocks creation during message processing.

Note, that presence of the abi parameter is critical for ABI compliant contracts. Message processing uses drastically different strategy for processing message for contracts which ABI includes "expire" header.

When the ABI header expire is present, the processing uses message expiration strategy:

• The maximum block gen time is set to message_expiration_timeout + transaction_wait_timeout.
• When maximum block gen time is reached, the processing will be finished with MessageExpired error.

When the ABI header expire isn't present or abi parameter isn't specified, the processing uses transaction waiting strategy:

• The maximum block gen time is set to now() + transaction_wait_timeout.

• If maximum block gen time is reached and no result transaction is found, the processing will exit with an error.

send_events enables intermediate events, such as WillFetchNextBlock, FetchNextBlockFailed that may be useful for logging of new shard blocks creation during message processing.

Note, that presence of the abi parameter is critical for ABI compliant contracts. Message processing uses drastically different strategy for processing message for contracts which ABI includes "expire" header.

When the ABI header expire is present, the processing uses message expiration strategy:

• The maximum block gen time is set to message_expiration_timeout + transaction_wait_timeout.
• When maximum block gen time is reached, the processing will be finished with MessageExpired error.

When the ABI header expire isn't present or abi parameter isn't specified, the processing uses transaction waiting strategy:

• The maximum block gen time is set to now() + transaction_wait_timeout.

• If maximum block gen time is reached and no result transaction is found, the processing will exit with an error.

NOTE: Available only for lib-node binding.