Automic Workload Automation

DESCRIPTION

This set of objects will allow you to export a single object in json format and import it in a target environment under a different name, at a specific location.

It is possible to export most object types, but it will not work with users, hosts (agents), clients, folders.

The first webservice job exports the object, the second Powershell job edits the .json output, and the third job imports the object in the target client.

PRE-REQUISITES

• BEFORE importing the objects, connect to Client 0.

In UC_SYSTEM_SETTINGS, set if not done already: 

In UC_EXT_INTERPRETERS_WINDOWS, there must be a ‘POWERSHELL’ entry like below:

• You need a REST WebService Agent and a Windows agent. Both agents must reside on the same host.

PREPARATION STEPS

• Import the xml.
• Set the agents and login in the jobs’ attributes.
• Adjust the REST Connection object ‘CONN.WEBSERVICEREST@AWA_REST_API’:

Replace <AESERVER> with the actual AE server’s hostname or IP.

The username and password must be the same for both clients (source and destination). In other words, the exact same user must exist twice: once in the source client, once in the destination client.

Also set the hostname.

• The objects should now be ready for the first transport.

HOW IT WORKS

• Start ‘JOBP@AWA_REST_API.EXP_CHG_IMP‘:

• Fill in the Promptset

• Then 

 The execution should complete within a few seconds.

• Connect to the target Client.
• The object as well as the target path have been created:

Feedback is welcome

Best regards,

Antoine

Hi Antoine,
nice, thanks!
I noticed thwo things:
1. the Powershell-Job doesn't catch errors.

2. After a successful import, when I search for the imported object in global search, and select "Show in Folder" I get redirected to the <No Folder>, even though the object was imported in the correct folder. Maybe an issue with the Rest API?

Anyway, nice example, thanks!

Philipp

Hi Philipp,

Thanks for your feedback. 

Yes the job can be enhanced, capturing errors sounds like a good improvement. I will work on it 

I tested and got the same issue with the object location. It looks like a bug... I will open an incident to report it.

Best regards,

Antoine

I have been playing around last couple of days with transporting objects via REST and it seems there are still some slight imperfections in this process. 

I stumbled upon following issues:

1. If you export a Webservice REST connection which has an authentication method configured but no host, port, realm 

the appropriate part of the JSON will look following:

{
"type": "4",
"name": "authMethod",
"value": "Basic"
},
{
"type": "4",
"name": "basicHost",
"value": "Basic"
},
{
"type": "4",
"name": "basicPort",
"value": "Basic"
},
{
"type": "4",
"name": "basicRealm",
"value": "Basic"
},

After import the values will of course be filled accordingly and you end up with Port: Basic   etc. 

2. If you export a Webservice Rest job which does not override the connectors' uri the following JSON is generated:

{
"type": "2",
"name": "uriOverride",
"value": "false"
}

Which generally would make sense, as false means you don't do it. But to my amazement this field is read directly as a string and you end up overriding your connections uri with "false"

The same issues occur in other fields like:

{
"type": "2",
"name": "resource",
"value": "false"
},

{
"type": "2",
"name": "response_part_0_file",
"value": "false"
},