GitHub Input node
Use the GitHub Input node to accept input from GitHub.
The GitHub Input node is available on Windows, AIX®, and Linux® systems.
This topic contains the following sections:
Purpose
Use the GitHub Input node in a message flow to accept input from GitHub. You can use the GitHub Input node to monitor GitHub for new or updated objects such as issues, commits, comments, and review comments. For example, the GitHub Input node might monitor a GitHub system for new issues. When a new issue is created, the GitHub Input node generates a message tree that represents the business object with details of the new issue. The message tree is propagated to the Out terminal so that the rest of the message flow can use the data to update other systems or to audit the changes.
The GitHub Input node operations are synchronous and non-transactional, which means that, if a message flow fails and rolls back after the GitHub Input node, the operation on the data source will still complete.
Using the GitHub Input node in a message flow
For information about using the GitHub Input node, see Using GitHub with IBM App Connect Enterprise. For information about obtaining connection details for GitHub, see How to use IBM App Connect with GitHub in the IBM App Connect Enterprise as a Service documentation.
Terminals and properties
When you put an instance of the GitHub Input node into a message flow, you can configure it. For more information, see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those without a default value) are marked with an asterisk.
The GitHub Input node terminals are described in the following table.
Terminal | Description |
---|---|
Out | The output terminal from which the message tree is propagated. The output message tree contains the object that is returned from the GitHub connector. |
Catch | The output terminal to which the message collection is routed if an exception is thrown downstream and caught by this node. |
Failure | If an error occurs in the GitHub Input node, the message is sent to the Failure terminal. |
The following tables describe the node properties. The columns headed M indicate whether the property is mandatory (marked with an asterisk on the panel if you must enter a value when no default is defined). The columns headed C indicate whether the property is configurable (you can change the value when you add the message flow to the BAR file to deploy it).
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | Yes | No | The node type,GitHub Input | The name of the node. |
Short description | No | No | A brief description of the node. | |
Long description | No | No | Text that describes the purpose of the node in the message flow. |
Property | M | C | Default | Description |
---|---|---|---|---|
Action | Yes | No | This property shows the action to be performed by the GitHub Input node. The action is defined through the Connector
Discovery wizard, and is then displayed in the Action property in read-only
format. Click Launch Connector Discovery to start the Connector Discovery wizard for the GitHub connector, and define the action that you require. |
|
Object | Yes | No | This property shows the object on which the specified action is to be performed. The object is defined through the Connector Discovery wizard, and is then displayed in the Object property in read-only format. | |
Schema base name | Yes | No | The base name of the schema file that describes the format of the message that is returned by the GitHub connector for the GitHub object. The schema file can be used by a Mapping node to map the data values that are returned. You can open the schema by clicking the Open schema button. |
Property | M | C | Default | Description |
---|---|---|---|---|
Policy | Yes | No | This property specifies the name of the policy that contains the details of
the security identity that is used for the connection. The policy has a type of
GitHub and is defined in a policy project. |
Property | M | C | Default | Description |
---|---|---|---|---|
Created timestamp field | No | No | This property specifies the field in the object that contains the creation
timestamp that is used to determine which objects are detected by polling and returned by the GitHub connector to the GitHub Input node. Objects created after the specified time are
detected and returned to the node.
|
|
Last updated timestamp field | No | No | This property specifies the field in the object that contains the last-updated
timestamp that is used to determine which objects are detected by polling and returned by the GitHub connector to the GitHub Input node. Objects updated after the specified time are
detected and returned to the node.
|
|
Format of the timestamps | No | No | This property specifies the format of the timestamps in the Created
timestamp field and the Last updated timestamp field of the
object. Enter a format for the timestamp by using letters. For example:
|
|
Timezone | No | No | UTC | This property specifies the time zone that applies to the timestamps. The default time zone is UTC (Coordinated Universal Time). |
Polling interval (minutes) | No | No | This property specifies the polling interval, in minutes, which controls how frequently the node checks for changes to the object. | |
Is created timestamp queryable | No | No | This property is applicable only for new events (CREATED_POLLER). If this property is selected, polling uses the Created timestamp field only. If it is not selected, polling uses the Created timestamp field and the Last updated timestamp field. |
Property | M | C | Default | Description |
---|---|---|---|---|
Retry mechanism | Yes | No | Failure | How the node handles a flow failure. Valid options are:
|
Retry threshold | No | Yes | 0 | The number of times to try the flow transaction again when the Retry mechanism property value is Short retry or Short and long retry. |
Short retry interval | No | Yes | 0 | The interval, in seconds, between each retry if Retry threshold property is not zero. |
Long retry interval | No | Yes | 300 | The interval between retries, if Retry mechanism property is Short and long retry and the retry threshold has been exhausted. |
Property | M | C | Default | Description |
---|---|---|---|---|
Message domain | Yes | No | JSON | The domain that is used to parse the response message. This property is set to
JSON and cannot be changed. |
Message model | No | No | The name of the message model schema file in which the incoming message is
defined. This property is set to the full filename of the response schema, which is the base name
set in the Schema base name property, suffixed with
response.schema.json (for example,
gen/flow1.GitHub_Input.response.schema.json ). |
|
Message | No | No | The name of the response message. The node detects the message type automatically; you cannot set this property. | |
Physical format | No | No | The name of the physical format of the response message. You cannot set this property. |
Property | M | C | Default | Description |
---|---|---|---|---|
Additional instances pool | No | No | None | The pool that is associated with the message flow. |
Additional instances | No | Yes | 0 | The number of additional instances. |
Property | M | C | Default | Description |
---|---|---|---|---|
Events | No | No | None | Events that you define for the node are displayed on this tab. By default, no
monitoring events are defined on any node in a message flow. Use Add,
Edit, and Delete to create, change, or delete
monitoring events for the node; see Configuring monitoring event sources by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled checkbox. |