Automic Continuous Delivery Automation

Expand all | Collapse all

Multiple Login mapping to Profile

Jump to Best Answer
  • 1.  Multiple Login mapping to Profile

    Broadcom Employee
    Posted 11-25-2019 08:42 AM
    Hi Team,

    We are trying to achieve an Application deployment, where we want to execute Component workflow with different Login credentials on the same agent.

    For the Project, we are setting up multiple targets for an environment (SIT), targets are mapped to the same Agent in this case.
    We are mapping Component(s) to those Target(s) in a Single Profile but it looks like only one Login can be mapped to a profile.   Is this possible to configure multiple login credentials using the same Profile?

    Any help would be appreaciated.

  • 2.  RE: Multiple Login mapping to Profile
    Best Answer

    Broadcom Employee
    Posted 11-25-2019 10:54 AM

    Hi @Jagan Sivanesan,

    in the Credentials view of an CDA-Login object you can specify depending on the Agent (column Agent / Name) which user-id (column Username / ID) and password (column Password) should be used.​​

    When * is used for the agent name the username and password is used executing jobs on any Agent.

    e.g. the view looks like this when different users should be used for executing jobs on different Agents

    AGENT-001 | WINDOWS | user123 | xxx | AutomationEngine
    AGENT-002 | WINDOWS | user789 | xxx | AutomationEngine


    Engineering Program Manager

  • 3.  RE: Multiple Login mapping to Profile

    Broadcom Employee
    Posted 11-26-2019 11:20 PM
    Thanks, Micheal. I kind of get your advice.

    But not sure if it will address my requirement,

    e.g. I have an Agent WIN01, There are 2 components/targets 1. JBoss WAR File 2. Script File-based both needs to use the same Agent WIN01.

    But for the JBoss target/component, I want to use jbossadmin user (login) and for file-based target/component I want to use fileadmin user (login) - both on same agent.

    In this case how using (*) can help me when I use one profile for 2 components/targets?  anywhere I can configure "user" at the target or component level?

  • 4.  RE: Multiple Login mapping to Profile

    Posted 11-27-2019 04:43 AM
    Hi Jagan,

    is there anything that prevents you from storing the credentials in two custom type properties in the Deployment Target?

    Kind regards,

    Senior Consultant
    setis GmbH

  • 5.  RE: Multiple Login mapping to Profile

    Broadcom Employee
    Posted 11-27-2019 08:58 PM
    This is interesting but I'm not able to en-vision it. Let me explore..

  • 6.  RE: Multiple Login mapping to Profile

    Posted 11-28-2019 05:43 AM

    have you ever checked the content of the Action Pack PCK.ITPA_SHARED? There you will find a promptset and an include:


    When you have a JBOSS and a filenbased part of the deployment then this means you will have two different deployment targets. In both you can enter the same agent. But you can enter the different credentials into the corresponding fields of the properties coming along with their custom types. And for each job you can use them. Placed the promptset into the job (or jobplan) and put the include as the first line into the Pre-Process of the job. The AGENT field of the promptset will have an EXT:/-entry pointing to the correct property.

    So at runtime(!) the job will change AGENT and LOGIN property to the entries provided by the deployment targets the profile is just pointing to. It is mainly what Michael has proposed as a second point. But using the Action Pack will help you to set all things up dynamically.

    Kind regards,

    Senior Consultant
    setis GmbH

  • 7.  RE: Multiple Login mapping to Profile

    Broadcom Employee
    Posted 12-10-2019 11:10 PM
    Thanks Juergen.

    We kind of evaluated this (btw I'm new to Automic), looks like it a better approach with minimal dynamic configuration/changes.

  • 8.  RE: Multiple Login mapping to Profile

    Broadcom Employee
    Posted 11-27-2019 08:15 AM
    Hi @Jagan Sivanesan

    I see two ways:
    • run a second Agent on the same server and assign it to the second CDA-Deployment Target
    • set the AE variable &LOGIN# in you Component-workflow to another value

    Running a second Agent
    1. copy the existing Agent's configuration-file: copy UCXJWX6.ini Win02.ini
    2. open the new config-file and change the values for [GLOBAL] Name, [GLOBAL] logging,  [TRACE] file and [TCP/IP] port.
    3. add an entry in Service Manager (e.g. duplicate the existing Agent's entry) and adding the parameter -i Win02.ini
    4. start the Agent with the Service Manager
    5. check in client 0 if it connects to the AE
    6. enable the Agent for your client
    7. assign the new Agent to the proper Deployment Targets in CDA

    Set the AE variable &LOGIN#
    1. open the Component workflow in Process Assembly
    2. switch to the Variables screen
    3. modify the Value of the variable &LOGIN# e.g. set it to a Dynamic Property of the Component (create it in CDA) EXT:/myComponentLogin
    4. set the value of the CDA-component's Dynamic Property to the name of an AE-Login-object which has been created and configured upfront.
    5. if you are using different logins for different environments you can override the value of the Dynamic Property in each CDA-Profile accordingly.

    I personally would go for option 1 as this setup looks similar to a real environment with several different servers. You need not to change the logic when you will deploy this CDA-component to several different CDA-Deployment-targets in the future (e.g. you will deploy it to several different independent JBOSS-servers). You just have to create/modify Environments, Login-objects and Profiles.
    IMHO the additional load of the second Agent process on your test-server is neglectable.

    Engineering Program Manager

  • 9.  RE: Multiple Login mapping to Profile

    Broadcom Employee
    Posted 11-27-2019 09:02 PM
    Thanks for the detailed writeup.

    I like Option 1, as it separates running as the second agent where I can use the same Login object.

    Option 2, will/might have complexities in-case I use generic workflow across environments/change everywhere.