One Transaction Multiple Applications

For completeness. If you're going down the road of using a script (adaptor, post processing or message translator) this is a good start.

var trx =

    Packages.com.proxima.centauri.servicemodel.ServiceModelAPI.createConfigChangeTransaction();

  try {

    var pId =

         Packages.com.proxima.centauri.servicemodel.common.AbstractService.makeValidId(ApplicationName);

    var cId =

         Packages.com.proxima.centauri.servicemodel.common.AbstractService.makeValidId(TransactionName);

      var newService = trx.modifyService(pId);

        _Logger.info("LinkServices", "Adding Component child: " + cId);

        newService.addComponentChild(cId);

        trx.commit();

  }

  catch (ex) {

    _Logger.warn("LinkServices", "Configuration change failed: " + ex.message);

  }

  finally {

    trx.close();

  }

Good luck!

Mike

Thanks Mike!

I was doing 5 and started to have a fear of deleting the service model since it was difficult and slow to do. I will evaluate each since I have 100+ check total and ~12 of them fall under as troublemakers for this. 

By the way this is the use case for a dependency expression, ie the application uses an external service as opposed to a component where the metric/alert is an element of the service.  That of course limits the options you have to roll up the quality and can get confusing quickly.

Either way (component or dependency) I would implement option 4 but rather than use a config transaction you can simply generate a message and send it to another MT, ie Service Templates where you add a rule to create a link.  The rule type is Service Relationship, add properties for ParentID, ChildID and Type (Component or Dependency) and add a second action to apply the changes.  If there are many changes to make you can use the MT as a single transaction as well and just send a single commit once all processing is complete, synchronising on the correct event for this can be tricky as you don't know which event is the last and the poll finished event will arrive before the SMT is finished so I have implemented this as a scheduled event in  the past to see if any commits are needed.

I'd also delete all the rules in that MT beforehand as they are not applicable (since 11.1).  Do it in the XML restart the service (or send this message #ChannelFrom=Command|CommandTarget=ServiceTemplates|Command=LoadConfiguration)

If the service model is large I'd steer clear of options that duplicate services (options 1 and 2)

Note: In 12.1 there is a feature called Rule Editor that would be ideal for this but its a bit buggy and should be avoided until its patched so you must do this with post processing rules.  

There is also a link function in mojo.service