2 of 2 people found this helpful
You could use Application Service class as is or can create subclass and name it as Jobs and use it for storing Control_M Jobs.
The reason because, Application Service is something which is used to represent low level module of an Application. Here in your case Control-M is an Application and each Job is a Application service.
Sateesh Kulkarni, that makes sense, thank you. If I may, I have two follow up questions regarding relationships. We have most of our Applications mapped via Discovery, so I'm thinking the individual jobs should be related to the application that they support (the jobs don't support "Control-M", they support their specific application). APPLICATIONSYSTEMCOMPONENT seems like the most fitting relationship name, is that correct?
Also, these jobs have predecessor/successor relationships between them that we want to track, however they aren't technically dependent on each other.
For example, if Job1 is the predecessor to Job2, it's possible that Job2 could still be successful even if Job1 failed. Would you still use the Dependency relationship and just set the HasImpact attribute to No? Is there an existing relationship that fits better, or do I need to create a new one?
Thanks again for your help,
1 of 1 people found this helpful
The correct relationship class between Application and Application Service is BMC_ApplicationSystemServices. Yes name can APPLICATIONSYSTEMSERVICES or APPLICATIONSYSTEMCOMPONENT.
Dependency can be used to represent the flow between Jobs,no need to represent Impact and as they all are independent.