Part 2: Isolating work- and configuration items (Creating custom controls / lists to extend sementation)
Part 3: Restricting forms and controls (Altering default controls to enforce RBAC)
Part 4: Scoped work- and configuration item creation (“Create From Template” task: how to apply everywhere)
Part 5: Control work-item movements (Showcase of community tool which allows scoped transfer of tickets)
Part 6: Setting up an optimized, shared view structure (how to increase your users’ efficiency)
Part 7: Business Intelligence (how to present data in the multi-tenant ITSM platform)
Linking work- and configuration items to their tenants
In the previous blogpost, I outlined the basic scenario and concepts towards providing a multi-tenant Service Manager platform for your company’s departments.
In order to distinct between a ticket or CI belonging to the Finance or HR department, we need to tag each item with a value unique for each part of your company.
One of the fields that is a suitabe candidate for such use is the “support group” property. This is an out-of-the-box function for incidents and requests, and is used
to specify which IT team is currently task to treat it.
It is easy to extend this use to support multiple departments in a company instead of multiple teams within a single department by adding an additional layer in the support group hierarchy:
Note: as not each department might need multiple tiers for their service management execution, the sub-tiers may be variable in count. It is recommended to setup at least one sub-tier for each department (call it ‘Default’ or ‘General’ for example) to be consistent with the hierarchy structure.
This allows to not only isolate and identify tickets between departments, but also enable each department to use their own escalation chain! By using per-derpartment security roles and restricted forms (described in a later post), we can easily provide users with only the items they need to maintain.
However, the support group field is not present on all items. CI’s, problems and changes do not have this field. This is not an issue when using the platform in a single department as problems and changes are usually not part of an hierarchic assignment process. In order to be able to isolate these types of items in the same way we can do with requests and incidents, we’ll need to add this field where needed.
This can be done using some XML authoring and C# SDK usage.
Scenario: adding a ‘support group’ field to the problem work-item type
If we want to have department users to utilize a problem management process, they need to be able to work with problems in SCSM without interference of items created by other teams.
Extending the problem class
Before we can show anything in the console / portal, we need to add a new list ‘Problem Support Group’ and link it to the problem class.
The management pack snippet above will define a new list “Problem Support Group” and link it to a new field “SupportGroup” which is added to the problem type.
When we now open the problem form, we can see the new field in the ‘extensions’-tab:
We can also see and populate the list in the lists overview in the authoring pane:
“Ok, great, but I want to integrate this field with my problem form, instead of having it in a separate extension-tab”
This is where the seconds step comes in:
Adding fields to existing forms
Adding fields to existing forms can be done in 2 ways:
Using the management pack Form-tag
The SCSM management pack structure allows you to define overrides for existing forms like this:
There are 2 ways to use this XML feature to setup the form customization:
Specify the customizations directly in XML
This is the most easy way and also the method used by the SCSM authoring tool (which you should use if your not familiar with the XML syntax)
Not all modifications work, caused by (what I assume) are layout operations (executed by form-code) hapening after the customization is applied
Add a custom user-control (through a DLL) and have it manipulate the form to add extra controls
This allows you the most control over what will happen as you can use all SDK features instead of the limited XML customizations
Not for the faint of heart, although this sample will help you to get the picture :)
I will describe the last option as it is the least documented one on the internet (and also my favortie option ;)
Create a new WPF User Control Library in Visual Studio. All the info is in the old, but gold article from Anton Gritsenko here
Modify the user control so that it is invisible (we only need the code-behind, not the actual layout functions). Setup an event handler for the datacontextchanged-event. This will enable us to execute code once the SCSM form is loaded with data.
Setup the code so that it will get the location of the form where the existing problem controls are present, and then add and bind our custom controls
Reference the assembly in the MP project and make sure that ‘Package to bundle’ is enabled in the reference properties
Build the User Control project, and check the MP -tag to make sure that it recognizes the generated DLL (MP Authoring autocomplete does this)
Build the MP and copy the generated MPB-file from the bin/debug folder into your management group
The field should now be added to the problem form
We can now use this field in forms, views, security roles. The problem work-item type is ready for multi-tenant use!
The full project can be found here. I hope it helps you putting 1 and 1 together and setup your own customizations :)