Page History
...
Anchor | ||||
---|---|---|---|---|
|
register
export
- Allows to export objects such as workflows to an archive file in .zip or .tar.gz formatregister a Controller. The command comes in two flavors:
- export individual objects specified by register a Standalone Controller using the
--path
and--type
options.primary-url
option. - register a Controller Cluster using Should relative paths be used in the archive file then the
--
startprimary-
folder optionurl
and--
use-short-path switch can be applied. - export objects from folders using the
--folder
option and--recursive
switch.- Optionally one or more object types can be specified and otherwise all objects will be exported, see
--type
option. - Should relative paths be used in the archive file then the
--use-short-path
switch can be applied. - Export of objects can further be limited by use of the
--no-*
switches, see section Switches.
- Optionally one or more object types can be specified and otherwise all objects will be exported, see
- export individual objects specified by register a Standalone Controller using the
- The archive file is specified from the
--file
and--format
options. - If JOC Cockpit is operated for the High Security Level then the
--for-signing
switch can be used to export Controller Objects that should be digitally signed. Objects and signatures can be imported using theimport-deploy
command.
- Allows to export objects such as workflows to an archive file in .zip or .tar.gz formatregister a Controller. The command comes in two flavors:
import
- Imports an archive file to the inventory. The operation applies to use of JOC Cockpit with the Low and Medium Security Level.
- Users can specify if existing objects will be overwritten or if duplicate objects from the import file will be assigned a prefix or suffix or will be ignored.
- import-deploy
- Imports an archive file to the inventory and deploys the included objects. The operation is applicable if JOC Cockpit is operated for the High Security Level.
- As a prerequisite the archive file must be exported using the
--for-signing
switch. - Workflows and Job Resources from the archive file are digitally signed by the user. Signature files are added to the archive file.
- As a prerequisite the archive file must be exported using the
- On import the objects in the archive file are deployed to related Controllers as specified during export.
- Imports an archive file to the inventory and deploys the included objects. The operation is applicable if JOC Cockpit is operated for the High Security Level.
deploy
- Allows to deploy Controller Objects such as workflows. The command can be used in two flavors:
- deploy individual objects specified by the
--path
and--type
options. - deploy objects from folders using the
--folder
option and--recursive
switch.
- deploy individual objects specified by the
- Deploying objects forwards them to Controllers and Agents.
- More than one Controller ID can be specified like this:
--controller-id=controller-uat-1,controller-uat-2
- More than one Controller ID can be specified like this:
- Allows to deploy Controller Objects such as workflows. The command can be used in two flavors:
revoke
- Allows to undeploy Controller Objects such as workflows. The command can be used in two flavors:
- revoke individual objects specified by the
--path
and--type
options. - revoke objects from folders using the
--folder
option and--recursive
switch.
- revoke individual objects specified by the
- Revoking Controller objects deletes them from the Controller and Agents, objects remain in draft status in the inventory.
- More than one Controller ID can be specified like this:
--controller-id=controller-uat-1,controller-uat-2
- More than one Controller ID can be specified like this:
- Allows to undeploy Controller Objects such as workflows. The command can be used in two flavors:
release
- Allows to release Automation Objects such as schedules. The command can be used in two flavors:
- release individual objects specified by the
--path
and--type
options. - release objects from folders using the
--folder
option and--recursive
switch.
- release individual objects specified by the
- Releasing objects activates them for example for use by the Daily Plan.
- Allows to release Automation Objects such as schedules. The command can be used in two flavors:
recall
- Allows to unrelease Automation Objects such as schedules. The command can be used in two flavors:
- recall individual objects specified by the
--path
and--type
options. - recall objects from folders using the
--folder
option and--recursive
switch.
- recall individual objects specified by the
- Recalling objects deactivates them from further use, objects remain in draft status in the inventory.
- Allows to unrelease Automation Objects such as schedules. The command can be used in two flavors:
store
- Allows to store an object such as a workflow or schedule from a file to the inventory.
- The
--file
option specifies the file that holds the JSON representation of an object. - The
--type
option specifies the object type. - The
--path
option specifies the folders and object name of the objects inventory location.
- The
- Objects are stored to the inventory in draft status and can be deployed or released using the related commands.
- Allows to store an object such as a workflow or schedule from a file to the inventory.
remove
- Allows to remove objects such as workflows or schedules from the inventory. The command can be used in two flavors:
- remove individual objects specified by the
--path
and--type
options. - remove objects from folders recursively using the
--folder
option.
- remove individual objects specified by the
- Controller objects such as workflows are removed from the Controller and from the inventory. Automation objects such as schedules are removed from the inventory.
- Removing objects moves them to the trash from which they can be restored or deleted
- Allows to remove objects such as workflows or schedules from the inventory. The command can be used in two flavors:
restore
- Allows to restore objects such as workflows or schedules from the trash. The command can be used in two flavors:
- restore individual objects specified by the
--path
and--type
options. - restore objects from folders recursively using the
--folder
option.
- restore individual objects specified by the
- Restoring objects moves them from the trash to the inventory from which they can be deployed or released.
- Allows to restore objects such as workflows or schedules from the trash. The command can be used in two flavors:
delete
- Allows to delete objects such as workflows or schedules from the trash. The command can be used in two flavors:
- delete individual objects specified by the
--path
and--type
options. - delete objects from folders recursively using the
--folder
option.
- delete individual objects specified by the
- Deleting objects will permanently wipe them from the trash.
- Allows to delete objects such as workflows or schedules from the trash. The command can be used in two flavors:
secondary-url
options.
- The URLs specify the protocol, host and port by which the Controller instance can be accessed from JOC Cockpit, for example
http://localhost:4444
. - Controller instances are assigned a Controller ID on installation. When registering the Controller it will automatically use the given Controller ID.
unregister
- Allows to unregister a Controller specifying the
--controller-id
option. Unregistering a Controller deletes the Controller and related Agents from the inventory
- Allows to unregister a Controller specifying the
- check
- Tests the connection between JOC Cockpit and a Controller instance. The operation is available before a Controller is registered.
- The
--controller-url
must be specified that is used from JOC Cockpit to connect to the Controller.
store-agent
When Agents are stored, then they are added or updated in the inventory and are set to the not deployed status. The command comes in two flavors:
- store Standalone Agent: requires to specify the
--agent-id
option that holds the unique identifier of an Agent. The Agent ID cannot be changed later on. The--agent-name
option specifies the unique name of an Agent that can be changed later on. The--agent-url
option specifies the protocol, host and optionally port by which the Agent can be accessed from the Controller.. - store Agent Cluster: requires to specify the
--agent-id
and--agent-name
options. An Agent Cluster includes a Primary and Secondary Director Agent.- The Primary Director Agent is specified from the
--primary-subagent-id
and--primary-url
options that are use similarly to above--agent-id
and--agent-url
options. - The Secondary Director Agent is specified from the
--secondary-subagent-id
and--secondary-url
options that are use similarly to above--agent-id
and--agent-url
options.
- The Primary Director Agent is specified from the
- store Standalone Agent: requires to specify the
- The
deploy-agent
command can be used to deploy the Agent configuration.
delete-agent
- When Agents are removed, then they will be deleted from the Controller and from the inventory.
- The command is used with the
--agent-id
option to identify the related Agent.
deploy-agent
- When Agents are deployed, then the Agent configuration will be made available to the Controller which connects to the related Agent. As a prerequisite for deployment the Agent must be up & running and must be reachable for the Controller to establish a connection. The same applies to Subagents that have been added to an Agent Cluster using the
store-subagent
command. - The command is used with the
--agent-id
option to identify the related Agent. For deployment of an Agent Cluster the--cluster
switch must be used.
- When Agents are deployed, then the Agent configuration will be made available to the Controller which connects to the related Agent. As a prerequisite for deployment the Agent must be up & running and must be reachable for the Controller to establish a connection. The same applies to Subagents that have been added to an Agent Cluster using the
revoke-agent
- When Agents are revoked then the Agent configuration is deleted from the Controller, but remains in place with the inventory and will be set to the not deployed status.
- The command is used with the
--agent-id
option to identify the related Agent. For revocation of an Agent Cluster the--cluster
switch must be used.
store-subagent
- Subagents are used in an Agent Cluster acting as worker nodes to execute jobs. When Subagents are stored, then they are added or updated in the inventory and will be set to the not deployed status. Subagents are not deployed individually. Instead, they are deployed with the Agent Cluster using the
deploy-agent
command. - The command is used with the
--controller-id
and--agent-id
options which identify the Agent Cluster. The--subagent-id
and--subagent-url
options specify the unique identifier of a Subagent and its URL.
- Subagents are used in an Agent Cluster acting as worker nodes to execute jobs. When Subagents are stored, then they are added or updated in the inventory and will be set to the not deployed status. Subagents are not deployed individually. Instead, they are deployed with the Agent Cluster using the
delete-subagent
- Subagents are deleted from the Agent Cluster and related Subagent Clusters. The operation deletes Subagents from the Agent Cluster and from the inventory.
- The command is used with the
--controller-id
and--subagent-id
options to identify the related Subagent.
store-cluster
- Subagent Clusters implement clustering from the selection of the Subagents involved and from the scheduling mode being active-passive (fixed-priority) or active-active (round-robin).
- logical
- To store a Subagent Cluster users speicfy the
--controller-id
and--agent-id
options that identify the Agent Cluster. The--cluster-id
option specifies the unique identifier of the cluster to be created. The--subagent-id
option specifies one or more Subagents spearated by comma that are used in the cluster. For an active-passive cluster the first Subagent specified will execute the jobs and if it becomes unavailable then the next Subagent will be used. - The
--priority
option specifies an active-passive or active-active cluster. The option accepts one fo the valuesfirst
(active-passive) ornext
(active-active). Default:first
.
delete-cluster
- The Subagent Cluster is deleted from the Agent Cluster and from the inventory. Subagents used in the Subagent Cluster are not deleted.
- The command is used with the
--controller-id
and--cluster-id
options to identify the Subagent Cluster.
deploy-cluster
- The Subagent Cluster is made available to the Agent Cluster. A deployed Subagent Cluster can be used for assignment to jobs.
- The command is used with the
--controller-id
and--cluster-id
options to identify the Subagent Cluster.
revoke-cluster
- The Subagent Cluster is deleted from the Agent Cluster but remains in place with the inventory and is set to the not deployed status.
- The command is used with the
--controller-id
and--cluster-id
options to identify the Subagent Cluster.
export-agent
Agent configurations can be exported to an archive file using the
--file
option. The archive file will be created in .zip or .tar.gz format using the--format
option. Default:ZIP.
import-agent
- For import of Agent configurations users can specify that existing Agent configurations with the same Agent IDs should be overwritten using the
--overwrite
switch
revalidate
- Allows to revalildate objects such as workflows or schedules from the inventory, for example after import. The command can be used for inventory folders.
- For import of Agent configurations users can specify that existing Agent configurations with the same Agent IDs should be overwritten using the
Anchor | ||||
---|---|---|---|---|
|
...
Users can register a Controller from its URL. Users can check if the connection between JOC Cockpit and Controller can be established. Unregistering a Controller deletes the Controller and related Agents from the inventory
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
# common options for connection to JS7 REST API request_options=(--url=http://localhost:4446 --user=root --password=root) # register Standalone Controller ./manage-controller.sh register ${request_options[@]} \ --primary-url=http://localhost:4444 --primary-title="Standalone Controller" # check Standalone Controller Connection ./manage-controller.sh check ${request_options[@]} --controller-url=http://localhost:4444 # unregister Standalone Controller ./manage-controller.sh unregister ${request_options[@]} --controller-id=controller |
...
When Agents are deployed, then the Agent configuration will be made available to the Controller which connects to the related Agent. As a prerequisite for deployment the Agent must be up & running and must be reachable for the Controller to establish a connection. The same applies to Subagents that have been added to an Agent Cluster using the store-subagent
command.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
# common options for connection to JS7 REST API request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller) # store Standalone Agent ./manage-controller.sh store-agent ${request_options[@]} \ --agent-id=StandaloneAgent --agent-name=StandaloneAgent \ --agent-url="http://localhost:4445" --title="Standalone Agent" # deploy Standalone Agent ./manage-controller.sh deploy-agent ${request_options[@]} --agent-id=StandaloneAgent |
...
When Subagents are stored, then they are added or updated in the inventory and will be set to the not deployed status.When
Subagents are not deployed individually. Instead, then they are made available to deployed with the Agent Cluster which connects to the related Subagent. As a prerequisite for deployment the Subagent must be up & running and must be reachable for the Agent Cluster to establish a connectionusing the deploy-agent
command.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
# common options for connection to JS7 REST API request_options=(--url=http://localhost:4446 --user=root --password=root --controller-id=controller) # store Subagents ./manage-controller.sh store-subagent ${request_options[@]} \ --agent-id=AgentCluster --subagent-id=Subagent_01 \ --subagent-url=http://localhost:4745 --title="Subagent 01" ./manage-controller.sh store-subagent ${request_options[@]} \ --agent-id=AgentCluster --subagent-id=Subagent_02 \ --subagent-url=http://localhost:4845 --title="Subagent 02" # delete Subagents ./manage-controller.sh delete-subagent ${request_options[@]} --subagent-id=Subagent_01 ./manage-controller.sh delete-subagent ${request_options[@]} --subagent-id=Subagent_02 |
...