Customize Your Actions
Intro to Actions
An Action is a selection of Functions and Procedures which are executed in sequence in order to provide the unique logic required for the deployment of each Component. You can create Actions or use the Built-in Actions. Actions are created with a graphical editor by simply dragging and dropping the Procedures and Functions that make up your Action.
In addition, a Custom Action can replace the usual Ortelius deployment engine processing by calling an external deployment engine or scripts that perform the deployment steps (Helm for example).
Procedures and Functions
Actions are used to customize Ortelius around deployments, and Tasks. For most users, no configuration of Actions is required. However, if you want to use your own deployment scripts, then you will need to use a Custom Action. This section will get you started on creating your own Actions.
Ortelius comes with a set of reusable Built-in Actions. An Action includes a set of Functions and/or Procedures which are executed in sequence to provide the logic of a Component’s deployment. Actions can also be used as Pre or Post deployment steps to an Application or Release.
Actions depend on Procedures and Functions to do the work. If you want to create a new Custom Action, you will need to define the Procedures and Functions that the Action will use before you create the Action. Alternatively, you can use the Built-in Actions, Procedures, and Functions, that ship with Ortelius for defining the Steps of your new Action. For most user, the Built-in Actions will be sufficient for working with standard environments like Docker Containers.
In addition, a Custom Action can replace the usual Deployment Engine processing by calling an external script that performs its own deployment activities. Custom Actions call Functions and Procedures that execute external process such as Helm or Ansible. Functions and Procedures can be:
Actions can be implemented in many ways including:
Written in DMScript - Ortelius' internal deployment scripting language. DMScript has access to the Ortelius Object Model. DMScript ships with several pre-installed Procedures and Functions. It is also easy to create your own and add them to the activities that can be used when creating your Components installation logic. For more information see Dmscript.
A ‘local’ script - written in any scripting language that is supported by Linux, and executes in the Ortelius Container mounted from the Docker Host.
A ‘remote’ script - written in any scripting language supported by the target Endpoint’s operating system and accessible to Ortelius. If allowed, the script is automatically copied to the target Endpoint and executed there. (Note: Copy remote must be set to TRUE at the Function or Procedure Level).
Actions can be invoked:
Before any Task in a Domain is executed: When the Task is created, a “Pre-Action” can be specified. This can be either a Procedure or a Function. The specified Procedure or Function is invoked before the Task is executed. If the Procedure or Function aborts or returns a non-zero return code, the Task itself is prevented from running.
After any Task in a Domain is executed: When the Task is created, a “Post-Action” can be specified. The specified Action is invoked after the Task is executed. This can be used to connect to external systems to notify others that a Task has been executed (for example, to notify a bug-tracking system that an Application Version has been moved to a Testing state).
As a stand-alone Action that can be invoked from the Ortelius User Interface: The Action is associated with a “Run Action” Task. When invoked, the Action is executed. A user can right-click on the Domain to view the Task to execute the Action. Alternatively, they can right-click on an Application or a Component. In these circumstances, the selected object is pushed onto the Stack and is available via the $application or $component objects. See DMScript Stack for more information.
Before an Application is deployed: An Application can be defined as having a “Pre-Action.” This can be either an Action or a Function. When the Application is deployed, this “Pre-Action” is invoked first before any other operation. If this Pre-Action aborts or returns a non-zero return code, the deployment itself will be prevented.
After an Application is deployed: An Application can be defined as having a “Post-Action.” When the Application has completed a deployment, this “Post-Action” is invoked. This can be used to connect to external systems to notify others that an Application has been deployed.
As a Custom Action for the Application: An Application can be defined as having a “Custom Action.” This “Custom Action” is then executed to deploy the Application. It is the responsibility of this Custom Action to deliver the update to the target Endpoints.
Before a Component is deployed to an Endpoint: A Component can be defined as having a “Pre-Action.” When a Component is being deployed to an Endpoint, the Component is processed, and the files are pulled from the Repositories and placed into the Dropzone. Any action defined as a Pre-Action to a Component is executed after the Dropzone has been populated from the Components but before the Component is pushed to the Target Endpoints. A Pre-Action to a Component can be used to manipulate files in the Dropzone before the files are delivered to the Target Endpoint (for example, a modification to a configuration file).
After a Component is deployed to an Endpoint. A Component can be defined as having a “Post-Action.” When a Component has been deployed any “Post-Action” is executed. A Post-Action to a Component can be used to run scripts on the Endpoint after the files have been delivered (for example, to install SQL changes or restart the Application Server).
As a Custom Action for the Component. When a Component is defined, it can have a Custom Action associated to it. This Custom Action is then executed to deploy the Component. It is the sole responsibility of this Custom Action to deliver the update to the target Endpoint. Use a Custom Action when the delivery method differs from the usual “push files” mechanism – for example, invoking Ansible to install a piece of infrastructure or to issue a RESTful call to update the configuration of a load balancer.
The Action List View for Adding or Deleting
From the Action menu option to the left of the Ortelius main panel, you will be taken to a list of all available Actions which you have access to based on the Domain. You can also use the Filter bar, represented by a funnel icon, to reorder your Actions List View. You can filter on:
The Action List View has the following Tabs.
|Refresh||Refreshes the browser.|
|Add||Allows you to Add a new Action.|
|Delete||Deletes the selected item.|
From the Action List View, double click on the Action to view the details.
Using the Action Dashboard for Viewing and Editing
The Dashboard view displays all information related to a specific Action.
|Full Domain||The fully qualified Domain to which the Action belongs.|
|Name||A unique Name that describes the Action.|
|Summary||A brief description of what the Action does.|
|Category||Categories are used to arrange Actions in an orderly manner. Assigning a Category to an Action allows lists of Categories to be used throughout Ortelius. Clicking on an individual Category expands the list and shows all Actions that belong to that Category. You can add a new Category by simply adding it to the list using the entry field. Pre-defined Categories include:
|Owner Type||User or Group|
|Owner||The User or Group name of the Action’s owner. The default owner is the User who created the Action.|
|Created||An auto generated date when the Action was created (read-only).|
|Modified||An auto generated date when the Action was last modified (read-only).|
|Display Name||You can use this field to create a more user friendly name for your Action|
The Access Section allows Users within designated Groups to update the Action_ in various ways. To add a _Group_ to one of the access lists, drag and drop the _Group_ from the Available Groups list onto desired access list. All _Users_ who belong to a _Group_ that appear in one of the Access lists will be granted access to the _Action_ in the following ways:
|View||Allows Users to see the Action. If the User does not belong to a Group in the View Access list, the Action will not appear in the List View.|
|Change||Allows User to change the Action’s characteristics i.e. Name, Summary, etc.|
|Execute||Allows Users to execute this Action.|
NOTE: Ortelius has only two Groups, Administrators and Users. If you need more granularity in your UserGroups, you will need to upgrade to DeployHub Pro.
The Audit Trail displays audit entries for any changes or deployments that impact this object. It includes any changes in the object including User date and time, and deployments with unique numbers.
You can Subscribe to or Comment on an Audit Entry.
Subscribe: Allows you to receive information about the selected deployment.
Comment: Add information by clicking on the ‘Comment’ link within a text entry field. There is a field above the list labeled “Say something about this Application” that can have comments placed into it, and files can be attached to the comment as well. Enter text into this field to activate the Add Message button. Click to save the comment.
Add Files to Comments: Click on the paperclip icon to add a file to the message. Once added and you made a comment, click “Add Message”. Click on the paperclip icon to retrieve these attachments. The icon opens the line in the list to display the name of the file. Choose the file to download it into the your default Download directory on your local computer.
The logic of an Action is defined using a graphical drag and drop blueprint designer. A tree view on the right shows all the Functions and Procedures organized by categories that can be include in the Action’s logic. You can use the built-in activities for defining the logical steps of the Action or you can create new Procedures or Functions and have them available as activities to use. See Functions and Procedures for more information.
The blueprint designer contains all activities that make up the Actions logical processing steps, linked together in the order they are to be executed. Each step in the process has anchors where connections can be made. When you drag a item onto the designer, a blue input anchor is displayed at the top of the items “box.” You will see a green anchor at the bottom representing output. In this way you can create connections between the processes.
Click on one of the Categories in the list to see the available Functions or Procedures. Expand a Category and then select the desired Activity to drag and drop it into the Action blueprint area. It appears as a box containing the name of the Function or Procedure. It automatically links to the nearest “box” with a output anchor.
The Function or Procedure Parameter Dialog Box
The Parameter Dialog Box displays the options defined when the Function or Procedure was created using the Input Parameters Section from the Functions and Procedures Dashboard. When you add a new Function or Procedure to your Action blueprint designer, the Parameter Dialog Box will automatically display. If you are working on an existing Action and want to view the parameters, a right click will display:
- View Details - opens the Parameter Dialog Box
- Got to the Procedure - takes you to the Dashboard of the Function or Procedure. Your work will be saved automatically before navigating to the Functions and Procedures Dashboard.
- Delete this Activity - deletes the Function or Procedure from the blueprint designer.
An editor box opens automatically to set any input values required. If the dropped item is a Function, then an additional Result field is presented. This needs to be the name of a Variable that receives the result of the Function.
You can connect items in any order you require. To do this, left-click and hold down the button on one of the output anchors, then drag the resulting line onto another input anchor. This connects the items together and determines the order for processing the steps. The lines connecting items can be deleted by right clicking on the connector line and selecting “Delete this Connector”.
Some Built-in Functions and Procedures have more than one exit point. For example the “if” process can be used to create conditional branches where different routes are taken through the logic dependent on the evaluation of an expression. In such cases, there are multiple output “anchors” with labels (for example, true and false) which indicate the meaning of the anchor.
Some Built-in Functions and Procedures can contain other Action’s logic. When such Actions are dropped onto the blueprint area they are represented by a larger “box” containing a diagram showing the other Action. Double clicking on such an item will “drill down” into that item and open up another blueprint editor. Such Actions are typically “loops” (where the process “inside” the loop is executed for each iteration through the loop).
There are Procedures and Functions that ship with Ortelius, such as the Windows function ‘listservices’ and the WebSphere ‘DeployWS’ control procedure. These are editable (by an administrator with access to the GLOBAL Domain) just as any User defined Function or Procedure would be. There are also some Procedures and Functions that simply wrap around DMScript (such as “Loop through Array Keys”) that are not editable.
When the blueprint logic is executed, it’s first converted into a DMScript Procedure. DMScript is Ortelius' built-in Object-Oriented Scripting Language.
The integration work may already be done with our Built-in Actions. Some Built-in Actions are Functions or Procedures that can delete files in a DropZone, or run a PostGres script. Other Built-in Actions integrate with specific DevOps tools such as Ansible, Helm, Slack or GitHub.
Built-In Database Actions
|Run SQL Script (Postgres)||Runs one or more SQL scripts against a Postgres Database.|
Built-In Deploy Actions
|Checkout||Extracts items from the specified Repository and places them in the Dropzone.|
|Deploy||Extracts items from the specified Repository and deploys then to the Endpoints within the targeted Environment. Use IF conditions to filter the Endpoint list to those matching the specified criteria.|
|Deploy Component||Deploys the specified Component to the appropriate Endpoints within the targeted Environment.|
|Execute||Runs a script on the appropriate Endpoints within the targeted Environment. Use IF conditions to filter the Endpoint list to those matching the specified criteria.|
|Transfer||Deploys the Component on the stack to the Endpoint on the stack.|
Built-In Dropzone Actions
|Add File to ZIP||Puts a Dropzone file into a ZIP/WAR/JAR/EAR file.|
|Amend File Content||Modifies a flat file in the Dropzone. Set ““Server Specific”” to make a copy specific for each Endpoint.|
|Delete File||Removes a file from the Dropzone.|
|Extract File from ZIP||Extracts a named file from a ZIP/WAR/JAR/EAR file.|
|Iterate through Dropzone||Loops through each file in the Dropzone.|
|Remove File from ZIP||Deletes a file from a ZIP/WAR/JAR/EAR archive.|
|Rename File||Renames a file in the Dropzone. Set ““Server Specific”” to make a copy specific to the current Endpoint.|
|Using Dropzone||Use a named Dropzone.|
|XML - Add Element||Adds a New XML element.|
|XML - Remove Element||Removes an XML element.|
|XML - Set Attribute||Sets an attribute name in an XML element.|
|XML - Set Text||Sets the text in an XML element.|
Built-In Flow Logic Actions
|Calculate MD5||Calculates the MD5 of a file.|
|Get Directory||Returns the contents of a directory into an array.|
|Abort||Terminates a deployment with error condition.|
|Add Two Values||Add two values and stores the result in a variable.|
|Add Value to Variable||Add a value to a variable.|
|Echo||Echoes a message.|
|If||General Condition Expression evaluation. Also use this to filter the list of servers based on those matching the specified criteria.|
|Increment Variable||Increments a variable.|
|Parallel||Execute blocks in parallel.|
|Run Task||Execute a Specific Task.|
|Set Variable||Creates and sets a variable.|
|Sleep||Pauses for n seconds.|
|Using Stream||Use a named stream.|
|Wait for Task||Wait for a Specific Ortelius Task to be Run.|
Built-In Loop Actions
|Component Loop||Loops through each Component that makes up the Application.|
|Loop Through Array Keys||Loops through each element of an array, setting a variable to each key.|
|Server Loop||Iterates through the current set of Endpoints.|
|Version Loop||Loops through each version between version on target Endpoint and version being deployed.|
Built-In Tomcat Actions
|TomcatPostDeploy||Cleans work directory and starts Tomcat.|
|TomcatPreDeploy||Shuts down Tomcat before deployment.|
Built-In WebSphere Actions
|Deploy App||Deploys an Application to Websphere.|
Built-In Windows Actions
|Extract Zip||Extracts the contents of a zip file.|
|List Services||Returns a list of installed services into an array.|
|Start Service||Starts a Windows Service on the appropriate Endpoints within the targeted Environment. Use IF conditions to filter the Endpoint list to those matching the specified criteria.|
|Stop Service||Stops a Windows Service on the appropriate Endpoints within the targeted Environment. Use IF conditions to filter the Endpoint list to those matching the specified criteria.|
Built-in Actions that Support DevOps Interoperability
|Ansible||Uses Ansible to perform Deployments.|
|Cloud Foundry||Uses Cloud Foundry to perform Deployments.|
|Helm||Uses Helm to deploy Containers.|
|SalesForce||Deploys Applications to SalesForce.|
|Tomcat||Deploys to a Tomcat environment.|
|WebLogic||Deploys to a WebLogic Environment.|
|WebSphere||Deploys to a WebSphere Environment.|