The methods that you can implement in a .NETInput node depends on if you are using polling or event style message flows.
The API for the .NETInput node is called the Connector API. This API is in the IBM.Broker.Plugin.Connector namespace.
If the Start method throws an exception, then it does not influence the result of the deployment of the message flow. Such an exception reports an error to the system log, and the Start method is called again after a short wait.
Event Connectors
If you are using the event-driven style of .NETInput node, then you must register a user-defined delegate with the application that is the source of the events, which drive the .NETInput node. If you use the event-driven style and do not register a delegate in the Start method, then there is no way for the .NETInput node to propagate data to the message flow threads. The User Delegate method is responsible for creating NBEvent objects and passing them to the DeliverEvent method provided on the NBEventConnector class. The DeliverEvent method puts data on an in-memory queue, which the message flow threads access to pass the data in the NBEvent object.
Polling-driven Connectors
The integration node runs the ReadData method automatically after the message flow finishes deploying, when the Start method returns without an exception.
The ReadData method is responsible for taking data from the data source, if available, and returns an instance of the NBPollingResult object. If data is available, the returned NBPollingResult object is either a built-in NBByteArrayPollingResult, which creates the output message directly from the byte array, or a user-defined subclass, from which you can create the message tree manually.
See the following diagram for an example of using polling with the ReadData method.
If no data is available, the node developer returns an NBTimeoutPollingResult. When the ReadData method has finished waiting for the passed in timeout duration (T1), use the single-argument constructor for NBTimeoutPollingResult. If the data source does not allow a timed wait, use the two-argument constructor to return a timeout value back to the integration node. In this case, the integration node waits for this timeout interval (T2) before it calls ReadData again. This use of the method allows a developer for the .NETInput node to control the duration of the interval between polls (T2).
For example, you can implement a batch style of operation, requesting that the ReadData method is only called once per hour, or once per day.