TWA Next Release Cloud enablement team 2013, October 24th © 2013 IBM Corporation

Windows users in UPN format

Support UPN user format: create users

Support UPN user format: executing

Support UPN user format: Security file Enable escape character ('\') for '\' and '@' in LOGON attribute into Security file USER MAESTRO CPU=@+LOGON="tws_user",root,Domain@\\@,User@\@Domain.com BEGIN USEROBJ CPU=@+LOGON=Domain1\\@ ACCESS=ADD,DELETE,DISPLAY,MODIFY,USE,ALTPASS,LIST,UNLOCK,... JOB CPU=@+LOGON=Domain\\User1,User3\@Domain.com ACCESS=ADD,ADDDEP,ALTPRI,CANCEL,CONFIRM,DELDEP,DELETE,... Migration tool for Security file: updateLogonOnSecurityFile.sh (.cmd)

Firewall friendliness

IBM/service provider provides Workload automation as a service IBM/BP Customer Customer environment/LOB

Goals A firewall must be supported NAT must be supported Proxy must be supported No manual configuration on the agent side is required in case of changes on the master

Architecture Dynamic agents did not change for this feature Only outbounds communications are initiated All the communications can pass through the proxy NAT is supported No single point of failures Gateways can run parallel MDM BMDM Proxy GW1 GW2 DA DA DA Environment 1

Agent registration The gateway acts as a broker server for the agent The message is modified by the gateway to let the broker server know the agent is managed by this gateway Customizations of the MDM/BMDM are automatically replicated on the gateways Customization of the gateways are automatically replicated on the agents

Downcalls: Job submission The gateway acts as a broker server for the agent The gateway is immediately reacting to actions triggered by the broker server.

Automatic topology configuration For simple deployments, there is no need to know anything about gateway topology, they are automatically configured. For complex topologies, you can customise the connections (to meet firewall/network restrictions) MDM BMDM Proxy GW1 GW2 DA DA DA Environment 1

Security and multitenancy The connection to the MDM is authenticated using certificates. The connection to the MDM is authorised using certificates. Users and passwords are not required The connections from an environment/Line of business can access a limited set of resources (defined in the security file) MDM BMDM Proxy GW1 GW2 DA DA DA Environment 1

Variable passing

The problem In many scenarios the execution of a job feeds the input parameter of the execution of a subsequent job. The mechanism currently used to achieve this is to write something on a file system. Job A Job B Job A Job B The following limitations apply: Job A and Job B have to run on the same machine (or share the file system) Job A and Job B have to be scripts

The solution (TWS 9.1) Job A can update the variable table Job B can have a reference to a variable in the variable table The variable resolution should apply just before the start of Job B Job A Job B Job A and Job B can run on different machines Job A and Job B does not have to be scripts

Variable update and resolution Automatic resolution Variable update and resolution If Job A is a script, it can run composer to update the variable table If Job A is not a script, a bridge job can get the variables exported by Job A to update the variable table The job implemented by plug-ins are exporting data that can be read by a subsequent jobs. For example, the “Smart Cloud Provisioning” jobs are exporting the IP address of the provisioned machines composer Job A Job B Automatic resolution Job A Job B composer Job properties Job acting as bridge

Passing variables with job properties Job A exports a property. Script jobs can export any variable Job B references this variable in the job definition Job A and B must belong to the same job stream instance. Job A and B can run on different workstations Automatic resolution Job A Job B Job properties

Job stdout property Job A writes the stdout Job B gets the stdout of Job A as a property in the job definition Job A and B must belong to the same job stream instance. Job A and B can run on different workstations Automatic resolution Job A Job B Job stdout

Job stdout as stdin of subsequent jobs Job A writes the stdout Job B gets the stout of Job A as stdin Job A and B must belong to the same job stream instance. Job A and B can run on different workstations Job stdin Job A Job B Job stdout

Demo Message property imported in a variable Job output imported as standard in Job output imported as a variable