Core Actions
Discover the Power of Rewst Core Actions
The Core Actions in Rewst are your gateway to the platform's vast array of intrinsic functionalities. These actions, usable right out of the box, offer features ranging from ad-hoc HTTP requests to document parsing. This guide offers a comprehensive overview of each Core Action, its usage, and its capabilities, aiding you in designing robust, versatile workflows.
How to Use Core Actions
Core Actions are used in the same way as regular actions within workflows. They are selected from the list of available actions, configured based on their parameters, and then added to the workflow at the appropriate place.
Here are some details of the available core actions:
No-Operation (Noop)
Description: Does nothing. Often used for logic or as a placeholder in the workflow.
Parameters: None.
Output: None
Ad-hoc HTTP Requests
Performs an HTTP request to a specified URL, supporting a variety of methods, body content types, and configurations. This is useful for interacting with APIs or other web services within a workflow, or for performing any other tasks that involve HTTP requests.
Parameters
URL: The URL to which the HTTP request is sent.
Request Method: The HTTP method to use for the request. You can select from the dropdown options (
HEAD
,GET
,POST
,PUT
,DELETE
,OPTIONS
,TRACE
,PATCH
,PURGE
).Auth Username: The username for basic HTTP Authentication, if needed.
Auth Password: The password for basic HTTP Authentication, if needed. (This parameter is secret to ensure security.)
Allow Redirects: Specifies whether the HTTP request will follow redirects. By default, it's set to
true
.Body: The body to send with the request. This parameter is not required if
JSON
orFiles
is provided.JSON: The JSON body to send with the request. This field is not required if
Body
orFiles
is provided.Files: Here, you can add files to be uploaded with the HTTP request using
multipart/form-data
. Each file requires the following information:Field Name: The name of the form field (not the filename).
File Name: The name of the file.
File Contents: Contents of the file to upload.
File URL: A publicly-accessible URL to the file contents to upload.
Content Type: The MIME type of the file to include in the multipart field.
Cookies: Input the cookies to send with the request. You can add more than one cookie by clicking on the
+
icon.Headers: Specify the custom HTTP headers to be sent with the request. You can add more than one header by clicking on the
+
icon.Params: Enter the query parameters to be used with the HTTP request. You can add more than one parameter by clicking on the
+
icon.Timeout: Enter the timeout for the HTTP request in seconds. The default value is
5
.Require Success Status: If you check this box, the task will fail if a non-2xx HTTP status code is returned. This is useful for identifying and handling HTTP errors during the task's execution.
Output: The action returns the content returned by the server in response to the HTTP request. This could be a success message, a failure message, a data object, or any other content that the server sends as a response.
Note: If you need more advanced security around calling particular endpoints, you can also use a Custom Integration in addition to this HTTP Request action. This allows for enhanced security and customization when interacting with your external APIs.
Create & Await Webhook Actions
Create Webhook: Allows for the creation of a one-off webhook for which can then be used by the Await Webhook
action.
Parameters: This action requires the methods allowed to access the webhook, the response status, response headers, response body, and an expiration timeout.
Output: The output of this action is the webhook ID and the full URL of the webhook.
Await Webhook: Waits for a request to a created one-off webhook. Once a request is received, the workflow continues.
Parameters: This action only requires the ID of the webhook created from the
Create Webhook
action.Output: The output includes the HTTP method, query params, headers, JSON or form/multipart data in the body of the request, and the timestamp when the request was received.
Email, SMS & Confirmation Actions
Send Mail: Allows for the sending of an email.
Parameters: This action requires a sender prefix (
sender
), with multiple options available, the recipient's email address (to
), the subject of the email (subject
), the title of the email (title
), and the message body (message
). It also has the option to render markdown as HTML (render_markdown
).Output: The task doesn't yield an output upon success. It will fail if there are any errors during the process of sending the email.
Send SMS: Allows you to send a text message to a specified phone number.
Parameters: This action requires the recipient's phone number (
phone_number
) and the text message (message
) to be sent.Output: The output of this action will depend on the implementation details. Usually, it will return a confirmation message or an error message.
Confirmation Email: Sends a confirmation email with reply options to a specified recipient.
Parameters: This action requires the recipient's email address (
to
), the subject of the email (subject
), the title of the email (title
), and the message body (message
). It also offers user interaction buttons (buttons
) and has the option to render markdown as HTML (render_markdown
).Output: If the action is correctly executed, a confirmation email will be sent.
Delay Workflow Actions
Delay Workflow For Period: Pauses the workflow for a specified duration.
Parameters: The number of days, hours, minutes or seconds to delay the workflow.
Output: No specific output, the workflow resumes after the specified delay.
Delay Workflow Until Date/Time: Pauses the workflow until a specified date and time.
Parameters: The date and time when the workflow should resume.
Output: No specific output, the workflow resumes at the specified date and time.
Mock Task
Overview
The Mock
action is designed to provide you with the capability to simulate the result of a not yet implemented action. This is particularly useful during workflow development and testing phases as it allows you to simulate responses from services that are not yet available or are impractical to call during the development process.
When to Use
The Mock
action comes in handy in scenarios such as:
When designing new workflows where certain steps are not fully implemented.
In testing stages, to simulate conditions without making actual calls to the services.
To create controlled conditions in your workflow for troubleshooting issues.
Input Parameters
The Mock
action accepts the following parameter:
Mock Result: This parameter should contain the key / value pairs that you want to be returned by this action. You can press the
+
to add as many objects as necessary.
Example Usage
You are developing a workflow that is expected to interact with a service which is not yet implemented. You know the expected format of the response, and you want to build and test your workflow logic based on that response.
Let's say you know the response will look something like this:
{
"name": "Rewsty",
"valid": true,
"message": "Successfully completed the task."
}
You can simulate this response using the Mock
action as follows:
mock_result:
name: {{ CTX.name }}
valid: true
message: Successfully completed the task.
While using the Mock
action, the values can be literal Jinja expressions like {{ CTX.name }}
above. The action will return this exact input structure wrapped inside a data
object, and the Jinja expressions will not be evaluated but returned as is. The result of the action on the workflow results page would look like:
Result:
{
"data": {
"name": "{{ CTX.name }}",
"valid": true,
"message": "Successfully completed the task."
}
}
This can be useful for catching issues early in the development phase such as incorrect Jinja expression usage, understanding how the workflow will handle dynamic data, or verifying that your workflow is properly constructed to handle the expected responses from services. It's a way to ensure that your workflow behaves as expected when it starts receiving actual dynamic data.
Debugging with Templates
Overview
The Debug
action is a utility feature in our workflow system, specifically designed to assist with debugging and logging purposes. This action can help in understanding the flow of data within your workflows, troubleshoot problems, and generally help you understand what's happening at a certain point in the workflow execution. It logs the input parameters it receives and returns the same as its output.
When to Use
You might want to use the Debug
action in the following scenarios:
When developing workflows, to see how data is flowing between tasks and actions.
If you're troubleshooting an issue, to inspect the data that's being passed around.
When you want to log specific information for auditing or reporting purposes.
Input Parameters
The Debug
action accepts the following parameters:
text: This is a general-purpose text field that will be logged and returned by the
Debug
action.template: This field takes a reference to a template in your environment that will be rendered and used as part of the action's input. The system will replace any variables in the template with its actual value at the time of template rendering.
Example Usage
Let's say we have a template named "Greeting Message" with content # Hey there {{ CTX.name }}
.
We can use this template in the Debug
action with the following parameters:
text: Testing Debug Action
template: Greeting Message
Assuming CTX.name
is set to Rewsty
, the rendered template would be # Hey there Rewsty
.
The Debug
action will log these parameters and also return them as its output. The results of the action on the workflow results page would look like this:
Result:
{
"template": "# Hey there Rewsty",
"text": "Testing Debug Action"
}
This tells us that CTX.name
was set toRewsty
, and the text provided with this action was Testing Debug Action
. Using this, you can better understand the state of your workflow at the point this Debug
action was executed.
Parse HTML Action
Overview
The Parse HTML action is a versatile tool within Rewst, geared to pinpoint and extract specific elements or data from HTML documents. It leverages the power of BeautifulSoup, a Python library recognized for extracting data from HTML and XML files effectively.
When to Use
This action is particularly beneficial in these situations:
Data Extraction: capturing specific information from the response of an HTTP request.
Content Clean-Up: sieving out only the necessary data from complex HTML content.
Web Scraping: automating the extraction of specific information from various web pages using defined tags, classes, or identifiers.
Action Parameters
The Parse HTML
action accepts the following parameters:
HTML: The HTML content to be parsed. This could be HTML content from a webpage, obtained using the
HTTP Request
Core Action.Class: Optionally finds HTML elements based on their
class
attribute.ID: Optionally searches for HTML elements based on their
ID
attribute.Query: Employs BeautifulSoup filters to specify the operation type:
find_all
returns all instances of the defined HTML tag.