HTTP Form/POST Listener Configuration

Easily Configure an HTTP Form/POST Listener (Adapter) with the eiConsole.

With the eiConsole, the user can easily configure an HTTP Form/POST Listener or HTTP Connector. There are six tabs for the HTTP Form/POST Listener: Basic, Advanced, Transaction Logging, Inactivity, Throttling, WSDL. As with all the components of the eiConsole, the user is presented with a graphical interface with easy-to-configure screens.

Listener (Adapter) Configuration Drop-Down List

Basic HTTP Form/POST Listener Configuration Options

On the Basic tab, you can specify:

• Request Path – this will be the path appended to the standard eiPlatform URL that will be used as an entry point to this interface
• Wait for Response – this checkbox will let you determine whether or not to wait for a response (fire and forget or synchronous response)
• Timeout (Seconds) – specifies how long (in seconds) the Listener should wait for a response before timing out the connection

HTTP Form/POST Listener Basic Configuration Options

Advanced HTTP Form/POST Listener Configuration Options

On the Advanced tab, you can specify:

• Initialize on Trigger Only – if enabled, the Listener doesn’t start up until a trigger initializes it
• Allow Command-line Invocation – if enabled, the Listener can be invoked using the CLI client application
• Restart on Listening Error – if enabled, the Listener will be restarted after an error occurs
• FIFO Queue Name – the FIFO option enables a “First In, First Out” queuing mechanism between Listeners and Transports. If a FIFO Queue Name is provided, it will be used as a key for a transaction queue. Transactions will be written to this queue before they reach a Transport. The transactions in this queue will be ordered according to when they were created by the Listener.
• FIFO Queue Delay – this is the interval between updates or checks against that queue. Providing a queue name guarantees that a given Transport sends transactions in the same order the Listener created them in
• Servlet Path – specifies the HTTP servlet to listen to
• Process Multipart Body – specifies whether or not to parse a multipart body request
• Respond with Multipart Body – specifies whether or not the response should use a multipart body

HTTP Form/POST Advanced Configuration Options (top half of screen)

• Keep Message Body – specifies whether or not the output of the process should be the original multipart body

HTTP Form/POST Advanced Configuration Options (bottom half of screen)

Transaction Logging HTTP Form/POST Listener Configuration Options

When data is accepted through an HTTP Form/POST Listener, it is expected to arrive through a Web Form. The name-value pairs accepted through this Listener will be automatically converted into an XML format.

On the Transaction Logging tab, you can enable transaction events logging. That data can be logged by a Transaction Event Listener (TransactionEventListener).

• Transaction Logging Enable – this checkbox allows transaction events originating from this Listener to be logged by a Transaction Event Listener (TransactionEventListener)
• Log Transaction Data – if enabled, logs transaction data body
• Log Transaction Data Base64 – if enabled, logs transaction data body as Base64
• Log Transaction Attribute – if enabled, logs transaction attributes
• Log All Attributes – if enabled, no attributes will be filtered
• Allowed Attributes – attributes that are allowed to be logged

HTTP Form/POST Listener Transaction Logging Configuration Options

Inactivity HTTP Form/POST Listener Configuration Options

On the Inactivity tab you can specify:

• Enable Inactivity Monitor – check this box to enable inactivity monitoring – this will throw a non-transaction exception if the specified number of transactions haven’t been processed in the specified time interval
• Minimum Transactions to Expect – the number of transactions to expect to be completed per monitoring interval
• Monitoring Interval – how often to check that the specified number of transactions have been processed
• Times to Monitor – if set, monitoring will be done during the defined times of day – to ignore, set start and end time equally
• Days to Exclude from Monitoring – inactivity monitoring will not occur on the days specified
• Include Errors in Transaction Count – if checked, transactions that attempted to start, but failed at the Listener stage, will also be counted

HTTP Form/POST Listener Inactivity Configuration Options

Throttling HTTP Form/POST Listener Configuration Options

On the Throttling tab, you can specify:

• Throttling Mode – the throttling mode is used for limiting the number of transactions or messages emitted by this Listener. “Timed” will limit transactions based on time intervals, while “Concurrent” will limit based on a concurrent number of transactions. “Concurrent” mode requires a Throttling Response Processor step later in your interface workflow to acknowledge completion.

HTTP Form/POST Listener Throttling Mode

• Throttling Mechanism – the mechanism to use for throttling messages – “Blocking” prevents the Listener from continuing to process and emit messages altogether, while “Queued” pushes received messages into the interface queue or a default, in-memory queue.
• Max Concurrent Messages – how many messages can be concurrently processed, either by time-based limits (“Allow X per Second”) or synchronous (“Allow X at any Time”)
• Timed Emission Interval – the interval for time-based limits (“Allow X per X Timed Emission Interval”)
• Synchronous Timeout Interval – the interval to wait for a synchronous response before failing

HTTP Form/POST Listener Throttling Configuration Options

WSDL HTTP Form/POST Listener Configuration Options

On the WSDL tab, you can specify:

• WSDL File – WSDL file name that would be returned on request and ends with “?wsdl”. If you want to create new or edit existing files, you can click Edit/New to open the WSDL editor.
• WSDL Content Type – specifies the content-type to send with the WSDL file

HTTP Form/POST Listener WSDL Configuration Options