Defining Components

Component List View allows Adding or Deleting

Use the Component List View accessible from the left hand Component menu option to manage your Components Base Version and Component Versions. Because each Environment has a row where the Component Base Version or Component Version has been deployed, there can be multiple entries for the same Component if it has been deployed to multiple Environments. A list of all Components is organized by the following:

List Column	Description
Version	The Component Base Version or Component Version number.
Domain	The Domain to which the Component belongs.
Parent	The Component Base Version from which the Component Version was created. This will be empty for the Component Base Version.
Environment	The Environment to which the Component has been deployed. Each Environment will represent a different row in the List View table.
Last Deployment to Environment	The Deployment Log number.
Completed	The date and time of the last deployment to the listed Environment.
Results	Success or Fail.

Note: If you have not defined any Components to Ortelius, you will see only the sample data.

You can also use the Filter bar, represented by a funnel icon, to reorder your Component List View:

• Domain
• Environment
• Last Deployment
• Parent
• Result
• Version

Additional Tabs from the Component List View

Tab	Description
Refresh	Refreshes the browser.
+Add Base	Allows you to Add a new Component Base Version. You will select from one of three types: Container, Application File, Database
+Add Version	Creates a copy of the selected Component.
Delete	Deletes the selected item. However, you must delete the Components starting from the newest to the oldest. The Component Base Version would be deleted last. Sorting by “Version” gives you the order.
List	Return to List View if in the Map View.
Map	Displays a global Map of all Component versions, with their Application relationships.

Component Types

When adding new Components select the Component Type from the drop down list/:

Type	Description
Container	For Containers such as Docker.
Application File	For binary files such as .jar, .war, .ear, .exe, .dll, Linux executable files, Oracle Forms, or similar artifacts.
Database	For SQL files such as .ddl or other database update scripts.

How to View and Edit Components

Components are defined as Container, Application File, or Database. These are the different types of Components you may need from microservices to binaries and DB updates. The Dashboard view displays all information related to a specific Component Base Version or Component Version. Depending on what type of Component you are defining, you will be presented with different data definition fields.

The following fields are common to all Components:

Field	Description
Service Owner	The owner of the Component, whose default value is the creator of the Component.
Service Owner Email	The email of the owner. Important for knowing who to contact in the case of an anomaly.
Service Owner Phone	The phone number of the owner.
PagerDuty Business Service URL	Enter the address to the PagerDuty page that is associated to the business service for this Component.
PagerDuty Service URL	Enter the address to the PagerDuty page that is associated to the Component itself.
Slack Channel	Enter what Slack Channel that can be used to report issues about this Component.
Discord Channel	Enter the Discord Invite Link you would like your consumers to use for this Component.
HipChat Channel	Enter the HipChat Channel that can be used to report issues about this Component.
Full Domain	The fully qualified path of the Domain that the Component is to be associated, showing all parent Domains.
Name	The name of the Component.
Description	A short text field with a description of the Component.
Component Type	The kind of Component created, i..e. Container, Application File, or Database.
Endpoint Type	Used to map the Component to Endpoints within an Environment at deployment. This allows Ortelius to map the Component to the correct Endpoint when moving across different environments. You can add your own Endpoint Types from the Customize Types menu or select from the default options.
Category	Assigning a Category to an Object allows lists of Objects based on Categories to be used throughout Ortelius. Add a new Category in the entry field or use an existing Category displayed in the drop down.

A Container Component has the following optional attributes:

Field	Description
Build Date	The timestamp from when the last build job was run.
Build ID	The internal identifier for the Build Engine.
Build URL	The URL to the Build Engine.
Container Registry	The Container registry where the Container is stored.
Container Digest	The SHA number of the Container image.
Container Tag	The tag that was assigned to the Container image.
Helm Chart	The Helm Chart used to deploy the Component.
Helm Chart Namespace	The sub-division of the Kubernetes cluster where your Component Container should run.
Helm Chart Repo URL	Enter the URL to where the chart is located, for example: Bitnami, ArtifactHub, etc.
Helm Chart Version	The Helm Chart Version from the Helm Repository.
Git Commit	The Git SHA number. Populated when integrated into Continuous Delivery Pipelines.
Git Repo	The Git Repository that triggered the build.Populated when integrated into Continuous Delivery Pipelines.
Git Tag	The last tag for the Git Repository. Populated when integrated into Continuous Delivery Pipelines.
Git URL	The URL for the Git Repository.Populated when integrated into Continuous Delivery Pipelines.

Application File Type Specific Data Definition

Field	Description
Base Directory	Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
Target Directory	The directory under the Base Directory where the file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Build Job	The Continuous Delivery Build Job that is used to build/compile the Component.
Last Build Number	The number of the last Continuous Delivery (CD) Workflow that created the files referenced within the Component. This number will default to the Build ID if one is not set by the CD Workflow.
Build ID	The internal identifier for the Build Engine.
Build URL	The URL to the Build Engine.
Build Date	The timestamp from when the last build job was run.

Database Type Specific Data Definition

Database Components are used for making database updates such as table changes using SQL Scripts. Note: An database form (such as an Oracle Form) can be compiled and should be defined as an Application File not Database Component.

Field	Description
Base Directory	Base, or high level, directory where the file will be deployed. This value will be ignored if the Endpoint has a Base Directory defined. See Formatting Directories on the order of how the deployment directory is formatted.
Roll Forward Target Directory	The directory under the Base Directory where the Roll Forward file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Roll Forward Repository	Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories. Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level. Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war. Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level. Version Override: Overrides the default template of your versioning pattern defined at the Repository level.
Rollback Target Directory	The directory under the Base Directory where the Rollback file will be deployed, or final “Target” Directory. See Formatting Directories on the order of how the deployment directory is formatted.
Rollback Repository	Choose the Repository that contains your Roll Forward SQL. This list box is populated based on the Repositories pre-defined in your initial setup. Based on the Repository you select, you may be provided override or append fields if they were made available. For more information on Repositories see Connecting Your Repositories. Filepath Override: Enter a filepath that will override the default filepath defined at the Repository level. Pattern Override: Enter a pattern that will override the default pattern defined at the Repository level. Patterns are file types you want to pull from the Repository, such as *.exe, *.dll, *.war. Recursive Override: Select the box in order to override the default recursive behavior defined at the Repository level. This will turn recursion on or off depending on the setting at the Repository level. Version Override: Overrides the default template of your versioning pattern defined at the Repository level.

Endpoints

This section lists all Endpoints that the Component has been installed to with its Deployment Number. The Deployment Number is generated by Ortelius for each unique deployment. You can also use this section to stop incremental deployments and force a specific version to be deployed to the Endpoint. By manually adding a specific Component Version to the Endpoint, you bypass the incremental deployment logic of the deployment engine. For example, if you would like to deploy a particular container without accepting any intermediate updates, you would go to the intermediate Component Versions and manually add them to the Endpoints, causing the deployment engine to believe that it was previously deployed. When you manually add an Endpoint, the Deployment Number will show “manually deployed.” To manually add a Component to an Endpoint, use the +Add option. You will be provided a list of available Endpoints. Use Save to commit the change to the table. You can select multiple Endpoints. To Edit or Delete an Endpoint, select the Endpoint and use the Edit or Delete option.

Key Value Configurations

Key Value Configurations are Value Pairs for managing associative arrays assigned to the Object.

Key Value Pairs can be assigned at multiple levels, from the Global Domain down to an individual Component and have a “scope.” Lower level Objects can override a higher level Object. Below is the order in which Key Value Pairs can be overridden:

Object	Description
Global	Contains all Environment variables and any “additional Key Value Pairs” set by the user when running that task.
Environment	Overrides any Global Key Value Pairs during a deployment.
Application	Overrides the Environment Key Value Pairsduring a deployment.
Endpoint	Overrides the Application Key Value Pairs during a deployment.
Component	Overrides the Application Key Value Pairs during a deployed.

Key Value Pairs can be given any Name and a Value. Use +Add to add Key Value Pairs to the table. Use Save to confirm. Use the checkbox to Delete or Edit a Key Value Pair.

Deployed Environments for Component

A map showing all Environments where the Component is deployed.

Consuming Applications

This section shows a list of all Applications that are consuming this Component.

Component Readme

Give your users more information about your Container, Application File or Database Component. You can upload an external readme file to provide any information that you need to convey to your potential consumers. Use the ‘Upload’ option to select a file. It must be in text format. You can also automate the upload - see below.

Component Swagger

Publish your Swagger API definitions to provide further information about your restful APIs and the parameters needed. Ortelius takes your .json or .yaml file and renders it using Swagger. Use the ‘Upload’ option to associate your .json or .yaml file to that specific Component Version. You can also automate the upload - see below.

Component SBOM

Publish your Component’s SBOM to show packages and licenses your Component is consuming. SBOMs are required for populating the CVEs.

Component Vulnerabilities

Component vulnerabilities are based on your SBOM. Every thirty minutes, Ortelius updates the Component vulnerabilities based on OSV.Dev. For more information refer to OSV.Dev section of this documentation.

Component License

Report the license associated with your code base for your Component. Use the ‘Upload’ option to import your License file into Ortelius. The file must be in a text format.

Automate the Readme, SBOM, License, and Swagger Upload via Your Pipeline.

You can automatically upload you readme, SBOM, License, and Swagger data using the Command Line Interface (CLI) added to your pipeline. For more information review the CI/CD CLI details. You will find a complete list of parameters for collecting Swagger, SBOM and other tool reports and results. .

Audit Trail

The Audit Trail displays audit entries for any changes or deployments that impact this object. It includes all changes in the object including User date and time, and deployments with unique numbers.

For deployment audits, select a deployment number to see the details including:

Access	Description
Log	The output of the deployment.
Files	Any files or objects deployed.
Step Duration	Deployment Steps with time required to execute.
Feedback Loop	Shows what was updated starting from Component.

You can also Subscribe or Comment to an Audit Entry.

• Subscribe: Allows you to receive information about the selected deployment.

• Comment: Click on ‘Comment’ to add information. 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. Entering text into this field activates the Add Message button. Click to save the comment as a line in the list.

• Add Files to Comments: Click on the paperclip icon to add a file to the message. Once done, click on the “Add Message” button. These attachments can later be retrieved by clicking on the paperclip icon which then displays the name of the file within a list. Choose the file to download it into the your default Download directory on your local computer.

Access

The Access Section allows Users within designated Groups to update or view the Component. 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 Component:

Access	Description
View	This allows any User that belongs to any Group in this list to see the selected Component in the List View.
Change	This allows any User that belongs to any Group in this list to make changes to the Component.

Publish a New Component Version Based on an Existing Component Version

Create Component Versions that are patterned after the Component Base Version or any Component Version. Check the box Component Base Version or Component Versions from which you want to base the new version. Select the New Version Tab to access the Component Dashboard and then edit the new Component Version. When you manually create a new Component Version the name will be auto generated with a new number. You may need to provide it a unique name based on your versioning patterns.

Publish New Component Versions automatically via Continuous Delivery

Configure a continuous delivery system to automatically update new Component Versions each time a new GitCommit triggers the workflow process. Add Ortelius to the workflow to perform the continuous versioning of new Components and their consuming Applications. For more information, see Using Ortelius with CI/CD.

Component Dependency Map

The Dependency Map provides a graphical view of all Applications that is consuming this Component. This will remain empty until your Component is used by an an Application.