Automic Workload Automation

So just wondering how everyone else handles this and/or if anyone can confirm our approach is the best way to handle this or if there are other alternatives.

We have an include that we use to identify all the hosts in the system. It looks similar to this:

:SET &FTPSVR# = 'SERVERA'

:SET &FILESVR# = 'SERVERB'

Everyone puts this include in their job / object and then has access to all the hosts and can do PUT_ATT HOST = &FTPSVR#  etc.  This makes it easy to migrate objects between environments because you don't have to update the job at all - the include is different in each environment pointing to the correct server for that environment.

However, we're in the midst of a project to migrate some servers to newer servers.  These servers are on old OS's and we can't do an in place upgrade - we have to move to completely new servers.  Since these servers are used by many applications we can't just flip the switch one day and cut everyone over to the new servers at the same time.  We're migrating each application over one by one.

Which means, of course, with how things currently stand, we would have to add in new entries into our host include to point to the new servers. 

:SET &FTPSVRNEW# = 'SERVERC'

:SET &FILESVR# = 'SERVERD'

And then as an application migrates to the new servers they would have to update ALL their objects to replace &FTPSVR# with &FTPSVRNEW#.

This is painful and all I can think about is that in x years I'm going to have to do this all over again.  :-(

We'd like to implement something which would allow each application to cut over to a new server at their own pace and eliminate the need to have them update ALL their objects each time.

The only thing we can think of is to add additional entries in to the host include - one for each application.

:SET &APP1_FTPSVR# = 'SERVER1'

:SET &APP2_FTPSVR# = 'SERVER1'

:SET &APP3_FTPSVR# = 'SERVER3'

We have a lot of different applications, so this would be A LOT of entries.  But this would facilitate things so that next time we do this - when APP2 is ready to move over to the new server the only thing that has to be done is update the include for their application - everyone else would be unaffected.

But this really does not seem very efficient to have 30+ entries like this - one for each app - all pointing to the same server.  

Or maybe this is the best way.... that's my question.  Does anyone else do something similar and/or have any thoughts on this?  I might be overthinking this.  :-)

All suggestions appreciated.  Thanks in advance.

Hi

my thoughts on that...

out of my experience most admins/developers use a vara object to store all possible agents (and logins) in combination with one or more includes.

As far as I understood your post, its a logical issue, not a technical. The easiest way would be switching one in a bunch by replacing the old agent name with
the new agent name. As this is not possible I am afraid this will cause more work to do - independent from the way of implementation.
This means you have to switch the agent for every application seperately.

Of course in the current designed solution its a maximum of work to do as you have to touch every object separately that uses the agent :-(

For future implementations I would still use a vara object that holds all agents - per application as you suggested.

Optional you can use one or more includes to set agent & login.

Most of our departments use 2 different ENV Vara objects:
* System specific (means specific for the UC4 System,like TempFolder, DeploymentFolder, System specific parameters)
* Application specific (path definitions for external software, work directories, Agents, logins, shell sudos, APPparemeters,...)

In general I observed 2 attempts so far

A) catching (almost) everything per logic (script, config varas)
    Advantage: much config possibilities, less change effort for additional parameters for existig workflows
    Disadvantage: complicated script logic, huge amount of basic administration, complicated to debug in case of errors

B) keeping minimum logic to the jobs and workflows
    Advantage: easy to implement, easy to debug
    Disadvantage: much change work to do for maintenance/changes, not much functions configurable

hope this helps a bit
cheers, Wolfgang

Hi,

we found Hostgroups pretty helpfull at that point. As long as you use the same hostgroup names in every environment/client.

But this also has some downsides. There are objects that do not support hostgroups or only support one (like filetransfers). So you have to develop a diffrent solution in this case.

Regards, Matthias

in my opinion best way is to add application name to object name and prepare a logic to add host based on filter from object name. Maintain application / server details in vara object. 

If you already maintain app name in object name then you can try with the above logic.