This blog post is intended for developers and people doing advanced customizations in Service Manager.
Tasks are a key component of the Service Manager user experience and infrastructure. There are two different kinds of tasks:
All the links that you see on the right hand side of the console or forms are Console Tasks.
Console Tasks run locally on the same computer as the console and run under the security context of the user that the console is running as. They also run in the same process as the Service Manager console (Microsoft.EnterpriseManagement.ServiceManager.UI.Console.exe).
Runtime Tasks are tasks which are submitted to the Management Server to process. These are typically used in background workflows, but occasionally can be submitted when a user clicks on a Console Task. An example of this is the Synchronize Now task in the Connectors view.
When the user clicks on the Console Task, the code that runs actually submits a request to run a Runtime Task to the management server which then triggers a synchronization job for the selected connector.
Both Console Tasks and Runtime Tasks are defined in management packs. Console Tasks are defined as MP elements <ConsoleTask> and Runtime Tasks are defined as <Tasks>.
You can control which Console Tasks and Runtime Tasks are available for users to run using User Roles.
Security footnote intended primarily for developers: We don’t control security access by granting/denying visibility to console tasks. Permission to do things is centrally controlled at the Data Access Service. Because a Console Task runs under the security context of the console user and runs locally on the console computer, the user could write a custom program that directly accessed the Data Access Service that does the same thing as the Console Task. If the user has permission to do the action at the Data Access Service then he will be allowed to do it using the custom program (even if the Console Task is not granted that does the equivalent action). Granting/denying visibility to console tasks is really only intended to improve the user experience by removing actions that you don’t want people to run or that you know they can’t do anyways. Runtime Tasks on the other hand are secured at the Data Access Service because they run in an elevated security context and on the central management server. If you do not grant someone access to a Runtime Task, they will not be able to submit it. Further, the user must have permission to submit the Runtime Task against the target object.
So – in summary:
Next in this series, we’ll dive into Console Tasks in more detail.
Tasks Part 2 – Custom Console Tasks for Create, Edit, Delete
Tasks - Part 3: Command Line Console Tasks
could you please show us how to create user roles programatically?
@Archana - Can you please provide an example of what you would like to do?
Could you please show how to get the incident, that is active in moment, when I run some task.
I want to create task that changes state of current incident to the "Resolved" or some other state. So, how I can get this incident, that is current?
In other words, how can I programatically get the instance of Incident class, that is selected in view AllIncients, when I click on my custom task?
Sorry for my bad English =)
@!A.Zaviruha - I dont have time to provide a detailed answer on this right now but you can see an example of how to do this in this blog post and related source code example:
A client has the requirement that users be able to assign incidents to themselves, but nothing else until their name is against it. Is this possible using permissions to hide/show tasks? Or is it something that is not possible at all?
@Matt_Hall88 - Unfortunately I don't think that is possible with the SCSM security model as is.
Thanks Travis, I didn't think it was, just wanted to check!