Executing the SSH Shell v2.0 operation fixes the workers that will execute subsequent processing.
When SSH Shell operation (v2.0) is executed, the processing worker group of the subsequent step does not return to the worker group name "RAS_OPERATOR_PATH" even after "SSH Shell Logoff" steping, and always becomes "Worker_ <WORKER ID>".
The target operation is as follows.
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell Login
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Shell Logoff
Therefore, even when OO is configured as an OO cluster, Even if the worker goes down in subsequent processing, processing will not switch to the active worker.
When you execute SSH Shell operation (v1.0), the worker group of the subsequent step becomes the worker group name "RAS_OPERATOR_PATH".
Is this a specification?
I want the same specification as SSH Shell v1.0.
From the screenshots I am not seeing any differences even though I think I got your text explanation right.
Isn't it related to the fact that you might have opted to keep the session?
however, If you spotted differences feel free to open a support ticket so that someone will have a proper look and replicate and get back to you through the ticketing mechanism. A change might be due so you'll need the ticket anyway.
Thank you for an answer.
What will the ticket (a support ticket, ticketing mechanism) be?
Is it HPE company tech support teller? Or do you mean internal handling of OO?
Is a session SSH session?
Because I log off by "SSH Shell logoff" step, I think that the SSH session is not maintained.
If, in the case of OO cluster environment, WorkerGroup is "RAS_Operator_Path," Active Worker is chosen among plural Worker registered with "RAS_Operator_Path" automatically, and processing is carried out.
In the case of the following images, Worker handling is chosen among two Worker automatically.
In addition, Worker processing hears that there are fixed specifications than Engineer HPE Corporation until logoff processing is done for internal processing (transfer of SSH SessionID) when I use "SSH Shell" operation.
However, the state that Worker handling was fixed to is maintained though logoff processing was accomplished by "SSH Shell logoff v2.0" operation.
When one Worker falls though it is oo cluster environment, the flow cannot continue taking next step.
This event seems to occur also in "SSH Command v2.0". It also does not occur in "SSH Command v1.0".
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v1.0/SSH Command
/Base [1.9.1]/Library/Operations/Remote Command Execution/SSH/v2.0/SSH Command
SSH Command v2.0 of "SSH Command v2.0"
The worker group of "SSH Command v2.0" onwards will become a fixed worker.
SSH Command v1.0 of "SSH Command v1.0"
The worker group for all steps is "Ras_Operator_path"
Overall flow chart