Resource Action Nodes
The put
node in this circuit is a resource action node. It is a call to the AWS API $AWS$S3$PutBucketNotificationConfiguration
. To learn what this node does, select it and open the inspector (right sidebar):
Under Node details
, there is a link to AWS documentation for this node. Selecting it takes you to the AWS documentation of this API call:
Scroll down to the section on parameters to the API call:
Notice that Bucket
and NotificationConfiguration
are indicated as Required
parameters to the call. Now looking at the $AWS$S3$PutBucketNotificationConfiguration
node in Coreograph
we see that it has three input ports: Bucket
, NotificationConfiguration
, and OptionalParams
. The required parameters of each API are given their own input ports on action nodes. The remaining parameters, which are optional, are delivered as a tuple (which corresponds to a JSON object) in the final input port. Note however that in this example, the required input port Bucket
is not connected to anything. The API node also provides static versions of required and optional parameters. The second parameter port is called BucketStatic
, the third parameter is called NotificationConfigurationStatic
, and the fourth is called OptionalParamsStatic
. The first parameter port is called ClientOptions
, and is present on every action node. By default, resources are assumed to reside in the region that the CloudFormation template generated from the project is launched in. In this case, client options are not needed. It is possible to refer to a resource that belongs to a different region however, and client options are the means of doing so.
In this example, the Bucket
physical id is provided via the static BucketStatic
parameter port, and the NotificationConfiguration
is provided via the dynamic input NotificationConfiguration
.
The output of the action node is an HTTP request. It is ready to be sent over the network to the S3 service to perform this notification configuration action on the bucket. To do so, we send the HTTP request to the perform
circuit:
perform
occurs in many examples, because it is the standard way by which we make a client call to a service.