Each action in a Changeset represents an object being changed or an action to be performed.
The current supported actions types are:
- Configuration Actions
- Genesys Cloud
- Cyara CX Testing Actions
- Management Actions
- Email Actions
- Ansible Actions
- Generic API Actions
Configuration Actions
Configuration Action is available in the Genesys Engage environment. The following table explains the fields for the Configuration actions:
| Field | Description |
| Object Type | The type of the object that you want to use for the action. |
| Add Action Type | The type of the action that you want to add.Create: Create the selected object type.Update: Update the selected object type.Delete: Delete the selected object type. |
Genesys Cloud Actions
Genesys Cloud is available in the Genesys Cloud environment only. The following table explains the fields for the Configuration actions:
| Field | Description |
| Object Type | The type of the object that you want to use for the action. |
| Add Action Type | The type of the action that you want to add.Create: Create the selected object type.Update: Update the selected object type.Delete: Delete the selected object type. |
Cyara CX Testing Actions
InProd allows adding Cyara Voice campaigns as actions within a Changeset. As the campaign will take considerable time to finish, the results from running a Changeset will be emailed to the user once the campaign is completed.
The following table explains the fields for the Testing actions:
| Field | Description |
| Run Reply, Cruncher or Velocity Campaign | Run Cyara CX assurance campaigns |
| Update Dynamic Data Variables | Directly update Cyara unit test dynamic data variables |
Cyara Dynamic variables can also be updated within a Changeset action. The variable must already exist within the Cyara test case. The use of InProd variables is also supported on this action type.
With the use of this action type InProd, Changesets can be created that update Genesys call flow or IVR behavior and also update Cyara unit testings to ensure they do not fail as a result. Additionally, fully automated CX testing can be achieved by using InProd to set the correct state of the environment that is required for each test case.
Management Actions
Configuration Action is available in the Genesys Engage environment. Genesys Management Layer (Solution Control Server) actions can be added into a Changeset to enforce the running state of a given application.
The Start action fails if the Application does not enter into the Started state within the timeout value set in the Application objects. However, if an Application is already in the desired state, then no action will be taken.
For example “Switchover” will promote an Application from Back Mode into Primary Mode. If the Application is already in Primary Mode then no action is taken.
Management actions are highly valuable when performing changes to any HA Genesys application sets. A Changeset can easily be created which performs the following actions
- Ensure that the backup is in backup mode
- Update the backup applications configuration
- Restart the backup application
- Perform a graceful switchover of the backup application to primary
- Update the primary application, restart and switch over back to the primary state
The following table explains the fields for the Testing actions:
| Field | Description |
| Start Application | The action to start the application |
| Stop Application | The action to stop the application. |
| Stop Application Gracefully | The action to gracefully stop the application. |
| Application Switchover | The action to promote the application from Primary to Backup. |
Email Actions
The following table explains the fields for the Testing actions:
| Field | Description |
| Email Send | The action to send an email to the specified email address. |
Ansible Actions
Ansible is an on-premise feature only. With Ansible actions, you can call Ansible playbook from within the Changeset. Vice versa, you can also use the Changeset variables within the Ansible playbook.
The following table explains the fields for the Testing actions:
| Field | Description |
| Ansible Run | An action to run the specified Ansible script. |
In the Ansible script, all actions are specified as declarative that describes the desired state.
Note: For Ansible action, InProd supports Bastion / Jump host and cannot use external Ansible libraries.
After adding the Ansible action, you can choose several ways to select the script.
Playbook
Selecting this option opens the Playbook window where you can specify the action scripts.
Vault Password
Specify the password to access the Ansible Vault where the Ansible scripts are stored. InProd access the script files from the Vault.
Inventory
Specify the inventory data file in the YAML format. In this option, you can use Changeset variables.
Generic API Actions
With Generic API action, you can call external API services, which returns responses parsed by JavaScript code, accepting any response types (JSON, XML, HTML…).
The following table explains the fields for the Testing actions:
| Field | Description |
| Call Generic API | The action to call a generic API object. |
Use Generic API to retrieve or change data on external services and also perform actions on external devices. To support multiple use cases, the Generic API action supports different run types.
These run types can be called during:
- Run and validation of actions to test the login credentials or simple GET requests.
- Only on run, if the API call performs an action, such as Create, Update or Delete
Using Generic API action, you can also update the Changeset variables.
Properties supported in Generic API:
| Property | Description |
| Body | The body of the API. |
| Headers | The key/ value pair for the headers in the API. |
| Method | The HTTP methods to be used in the API. For example, Get, Post, Patch, Put, and Delete |
| Expected Result | The expected result of the method. Basically, these are the response codes, such as 200 OK, 201 Created, 400 Bad Result, 404 Not Found, and 405 Not Allowed. |
| Error On Failure | The Yes/ No value indicating whether to fail the API upon error in the API call.. |
| Only In Run | The True/ False value indicating whether to run the API only during run and not during validation. |
| Url | The URL of the API call. |
| Script | The script for the API. |