Request Queue: Difference between revisions

Latest revision as of 20:35, 26 August 2024

When you use one of the transactions within the application which has a output message defined for it the application will put a request in a queue. This queue holds a list of all the unprocessed messages and is polled by the Interface process. When the interface process is running the queue is normally empty. However if the interfaces are not running then all requests for output messages will be held in this queue until the interfaces are started again.

When messages have been processed you can check their status in the Interface Log.

The transactions which generate outbound messages are defined in Interface Admin and many of them depend on being enabled in the Locations screen.

Each item in the request queue will be assigned a unique Request ID and include a Transaction ID which links to the Pallet History table.

Revision as of 20:34, 26 August 2024 view source Dgarratt (talk \| contribs) Bureaucrats, Interface administrators, Administrators, writer 1,496 edits No edit summary ← Older edit		Latest revision as of 20:35, 26 August 2024 view source Dgarratt (talk \| contribs) Bureaucrats, Interface administrators, Administrators, writer 1,496 edits No edit summary
Line 7:		Line 7:
	The transactions which generate outbound messages are defined in [[Interface Admin]] and many of them depend on being enabled in the [[Locations]] screen.		The transactions which generate outbound messages are defined in [[Interface Admin]] and many of them depend on being enabled in the [[Locations]] screen.

	Each item in the request queue will be assigned a unique Request ID and include a Transaction ID which links to the [[Pallet History]] table.		Each item in the request queue will be assigned a unique ''Request ID'' and include a ''Transaction ID'' which links to the [[Pallet History]] table.