One Transaction Multiple Applications
I have a case where one Synthetic Monitor will be checking the port, for example, on a database. This is one check, but validates the database availability on 3 applications.
I need to figure out the best way to manage this in BSM since if something were to happen to this database I would want to make sure each application referenced this check's Service Quality. I am not sure what the best idea is to take on this situation since I could either look for this check then make x amount of messages for each application. Another way might be to do something with SMT processing to link all together perhaps. I have a very small subset of situations that will be like this and there might be more later when we add more applications into BSM.
Any ideas or tips on the best way to manage this would be appreciated.
Best Answer
Hi Jacob,
There are indeed a few ways to solve this. Let's go through the most obvious ones:
- If you are fetching the data using a script adaptor, like the mojo.dmi one, send several messages to the message translator with different application names.
- Pro: Quick.
- Con: Only possible when using a script adaptor and makes the service model bigger
- Create a message translator rule at the end of the message translator that changes the application name and ParameterId and sends several messages.
- Pro: Quick to implement; the message translator rules only get hit once.
- Con: Bigger service model
- Create a message translator rule that adds links from the applications to the service.
- Pro: Smaller service model; the message translator rules only get hit once.
- Con: Trickier to implement; only possible when there already is a service created, need to poll twice before the links are created after resetting the service model
- Create a post processing rule on the service model template that links the service up to the different applications.
- Pro: Smaller service model; the message translator rules only get hit once.
- Con: Trickier to implement
- Manually change the service model to add the relation.
- Pro: Quick if the number of connections is low.
- Con: Needs to be redone every time the service model gets reset.
- Create a separate adaptor that links the transaction to the applications when polling.
- Pro: Smaller service model; the message translator rules only get hit once. No need to change the message translator if you use the EUE adaptor.
- Con: Need to run separately from the other adaptor, adding a delay to the connecting when recreating the service model.
Personally I'd go for number 6 as I could handle the configuration externally without adding too much code into the polling of every message.Sure you could cache the configuration in the state object, but it would still impact the throughput of messages. I'd then create a csv file which tells the name of the transaction and the additional applications it should be linked to. The adaptor could then also be turned off when the service model was built out, not adding any overhead at all.
Kind regards,
Mike
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
That's what I thought at first but we don't know if the implementations are the same and my guess is the SMT uses the implementation from makeValidId so we should use the same or we might get incorrect ids generated.
