We have all had that issue with the Repository or the Orchestration Engine being unable to get to the gsoap web service URL. And, this is with all SBM components installed on the same server. Why can't it get to itself? Or in the case orchestrations, maybe we cannot figure out why the OE is unable to reach a third party web service.
Let's say you have a scenario where you would like Owners of items to be notified whenever any of their items are at risk of violating the SLA in 1 hour if they fail to action the item. Additionally, you might like to have a manager or supervisor (defined in a user field within the item) alerted if the item is still not actioned within 15 minutes of violation.
The problem is when you configure an action for SLAs to send notifications, the available IF conditions of the SLA action or properties of the SLA notification do not give you the ability to create a rule to utilize the (current user) dynamic variable to only send the notification to users populated in selected user fields within the item (such as the Owner). It only allows you to subscribe particular users statically which would normally be the manager/supervisor that oversees the entire project and needs to be aware of items that may or already have violated SLAs.
In order to fire off notifications to individual users selected in user fields within the items such as the owner of the item or perhaps a particular manager/supervisor that may change based upon the item, you can use the escalation options within that SLA notification to fire off a standard escalation notification in which you can create a normal rule that allows you to include the (current user) dynamic user variable.
Below is the procedure on how to set up such a solution using the aforementioned scenario. This article assumes you have already setup the terms of your SLA.
First, we'll need to create two escalation email notifications; one for the Owner and one for the Supervisor. Make sure to check the "Escalation" checkbox so this notification can only be tripped if executed by the escalation parameters of another notification which will be the SLA notification we'll create later. Make sure to select or create an appropriate message template:
Click the button to the right of the "When" field to create your When rule to restrict the recipient of the email to just the Owner of the particular item. If you wish, you can also include other user fields by simply repeating the condition with the appropriate user field joined by an "OR" operator.
If you wish, you can define Escalation conditions to continue sending the email to the user every X minutes/hours until the item is actioned as defined by your termination rule, most likely when the item changes state. Just keep in mind that the title of your notification would remain the same so "1 Hour to SLA Violation" would technically only be true on the first email they receive. You may want to change it to something open-ended like "SLA Violation Risk" if you decide to have it repeat.
Make sure to subscribe all users and/or groups that will be owners of items in this project.
If applicable in your case, create another escalation notification for the supervisor using the same process with appropriate value changes.
Now we'll need to go into the SLA section of the project to setup two SLA actions; one for triggering the notification to the owner with 1 hour to violation and another for triggering a notification to the manager/supervisor with 15 minutes to violation:
Under each action, configure the conditions appropriately:
If you need to specify any additional parameters in the 'IF' condition for your use-case, do so here.
Click the icon by "Run notification" to create your SLA notification. Since we cannot configure this notification to send emails to users selected in the item's various user fields dynamically, we won't need to have it run an action:
Name and save the notification then go under the Escalation tab to configure this notification to fire the escalation notification we created earlier for Owners. You will need to define a termination rule in order to utilize the Escalation Parameters, but it is logically irrelevant since we are looking to fire the escalation immediately "After 0 minutes":
Save the notification. Repeat those steps for the Supervisor (or any other) SLA alert action.
Once complete, users will receive notifications of items that are approaching SLA deadlines.
Self-signed can be a contentious term. Many would say a certificate is self-signed because it is not issued by a well-known certificate authority. Well-known can mean VeriSign, Go Daddy or your company's certificate authority. Using this definition does us a disservice because it complicates SSL/TLS language by using a practical definition instead of a technical definition.
Firstly, my huge thanks to all those customers who presented and contributed to iChange2016 in Chicago.
With over 78 sessions delivered, we could not have carried this off without you. Thank You.
All Track content is now available for review and download and you may access it here:
Lookout for further follow-up, and upcoming product VUGs and DevOps Drive-ins.