Announcement

Collapse
No announcement yet.

Templates in Problem Management

Collapse
X
Collapse
  •  

  • Templates in Problem Management

    Someone asked this question in the forums, and I thought this was a good topic to cover. SM has good potential to use Templates, and theoretically has the ability to use that in any module - including completely customized ones. But ironically enough, while some of the groundwork is there to enable Templates on the Problem Management module, it's like HP stopped part way through development and never finished it. So, this sounded like a good place to go through how to enable Templates for Problem Management.

    There are a couple of ScriptLibrary scripts at the heart of Templates in Service Manager; Template, TemplateFilter, and TemplateTables. I didn't write those at all, and this is just my understanding of how they work based on what they seem to do.

    The first step is the simplest (and what I thought was going to be the _only_ step for Problem Management). Menu Navigation -> Tailoring -> Document Engine -> Object to open the Document Engine Object record, and search for the "rootcause" Object record. In the Views/Templates, set the "Support Templates" checkbox to true.

    In the TemplateFilter.canModifyTemplate function, there is code to determine whether or not a user in a given module has access to use and create Template records. The OOB code on lines 99 - 103 has code in place for Problem Management (rootcause, rootcausetask, and knownerror).

    else if(tableName=="rootcause" || tableName=="rootcausetask" ||tableName=="knownerror")
    {
    if(system.vars.$G_rc_environment.modifyTemplate!=n ull && system.vars.$G_rc_environment.modifyTemplate)
    return true;
    }

    But while code is in place in the ScriptLibrary, the field it references in that code doesn't even exist in the rcenv dbdict record. There is no modifyTemplate field. So, we have to add it.

    Use Menu Navigation -> Tailoring -> Database Dictionary to access the dbdict application. You're going to need to add a modifyTemplate boolean field.

    Name: modifyTemplate
    Type: boolean

    At this point, stop and restart Service Manager.

    To make this new field available, you have to update the rc.profile.g record. It's simple enough to add a Checkbox form element. Use modifyTemplate as your input.

    The last steps are fairly simple; you just need to create the displayoption records. The two actions "createTemplate" and "applyTemplate" that are used in the displayoption records are considered base actions - that means that you don't need to update the Document Engine State record, just use them in the Action field of the displayoption record.

    Screen ID: rca.view
    Unique ID: rca.view_applyTemplate
    GUI Option: 214
    Text Option: 214
    Bank: 1
    Action: applyTemplate
    Default Label: Apply Template
    Text Alternative: Apply Template
    Condition: supportTemplates in $L.object=true and evaluate($L.tableAccess.update)

    Screen ID: rca.view
    Unique ID: rca.view_createTemplate
    GUI Option: 215
    Text Option: 215
    Bank: 1
    Action: createTemplate
    Default Label: Create Template from Record
    Text Alternative: createTemplate
    Condition: evaluate(nullsub(modifyTemplate in $G.rc.environment, false)) and supportTemplates in $L.object=true

    Now, for whatever reason, on the system I've worked on, there's some sort of issue with the datadict records and the Folders globallist. One of the functions of the tablefunctions Script in the ScriptLibrary is to look at the dbdict record to provide field captions for the field names, and to provide the values in the dropdowns. I'm not sure if it's because the Folders aren't being used in our environment or what, but, I got errors until I edited the datadict record.

    Type datadict in the command window to access the datadict record; search for the rootcause record. In the Validations tab, in the Global List column, scroll down to the folder field and remove the global list "Folder" from the column, and save the record. Stop Service Manager, start it back up, and there you go. You should be able to use and create Templates in Problem Management.

    • leonv
      #1
      leonv commented
      Editing a comment
      Another good post Jacob. Well done.

    • BeSIDE
      #2
      BeSIDE commented
      Editing a comment
      Hi Jacob,

      I had noticed the lack of time of development as well.
      The requirements are object and profile record(s).

      In migration projects we were asked for this as well. Also for configuration items. I think that might be an option while not using joindefs, or otherwise use this join name instead for the device filename. Similar for activity, not existing for configuration items, but if you use the joinname, then there is no problem to do so.

      If there are no other sources to parse ci's then using templates is a nice option.

      I think the development for SM7.00 had no followed up after the release.

      One other thing that might be interesting is to categorize templates, just while I like short lists instead of long lists:
      interaction > incident templates
      interaction > rfc templates
      change templates per category
      change task templates per change subcategory

      and the last thing if a change task template is set as default, it isn't taken into account when the change task is auto opened by change phase. I was just checking the options to replace an SD change-work order predecessor/successor flow in SM.
      Not really related to the topic, but it was an experience for me in the same project.

      Cheers,

      Barry

    • AFR
      #3
      AFR commented
      Editing a comment
      Thanks Jacob. Added this to my growing list of SM tips and tricks doco.
    Posting comments is disabled.

Categories

Collapse

Article Tags

Collapse

Latest Articles

Collapse

Working...
X