Type Projections in Inherited SR form

Steve_O'Connor

I've inherited from the default service request and added three new classes - its for a Folder Access Request. 2 are list values, 1 is a string. Without adding any type projections i get the dreaded Error “System.ArgumentException: propertyName” and the console crashes. This suggests I'm missing the TypeProjections for service request.

When I have done this before in another SR form, there were some TypeProjections already in the XML, so I added the default SR ones and it all worked. This XML however has none in it at all. So I added them below the EnumerationTypes element, which seems like the place they need to go.

However I'm struggling with the <TypeProjection ID => name and the <Type => I've tried a few variations and I either end up with XSD verification failed or it says the ID or type is already in use.

I did follow this: http://blog.scsmsolutions.com/2012/05/propertyname-error-on-form-targeted-to-custom-class/

and this: https://dynamicdatacenter.wordpress.com/2012/10/03/add-custom-service-request-forms-in-servicemanager2012/

But just can't seem to get it to work. I'd love any help or advice!

seth_coussens

First, I would ask why you want to use an inherited class, rather than just extending the base class with the new properties? If you extended the base class, you wouldn't have to worry about these issues and it would also file into line with what we consider to be best practice for adding new properties.

If you do have reasons for using an inherited class, I'd need to see the XML from you management pack in order to say what you have in there that needs to be corrected.

It sounds like you need to create a custom type projection and target the projection at your inherited class rather than the base service request class.

Steve_O'Connor

Hi Seth, we have the default form extended already with the Cireson time tracker, so my options are limited, hence the inherited class rather than extending. I would need to remove all of the timetracker XML from quite a few MP's.

I've attached the MP in question, would be great if you could have a look at it. I just need to figure this out once and should be good for future as well

joivan_hedrick

Try the following:

On line 65, you are creating a new type projection. I changed the name to have a unique ID, different from the OOB TP. 

On line 116, the target property works best with a typeprojection ID (internal name), not a class ID (internal name).  So I changed it to what was just created on line 65, "Custom_System.WorkItem.ServiceRequestProjection"

Give these two items a shot and see if it works for you. I would also strongly suggest breaking out the form into a different MP so that one MP has the class definition, and one MP has the form definition. 

Steve_O'Connor

Hi Joivan, that seems to have worked Only thing is the form is missing, but the extensions are there.

So I should just create a new MP and add the form to it instead now?

joivan_hedrick

Actually, I think I missed a step for inherited classes - see line 65. That Type Projection's Type property should target the previously-created class. It should be: 

<TypeProjection ID="Custom_System.WorkItem.ServiceRequestProjection" Accessibility="Public" Type="ServiceRequestFolderAccess">

Make that change and reseal/reimport. See if the form appears. Once it works, then yep, break it up into two different MPs. 

Steve_O'Connor

Thanks, that's looking better. Final question - is it only the new MP with the form that needs the assembly bundled into an MPB or both of them?

Thanks for your help, really appreciated!

Dan_Metzler

In looking at this thread, I have my own questions related to the Cireson Portal.  Can this custom service request based class be exposed in the Cireson portal?

I see lots of recommendations that say you should extend classes rather than inherit.  That all sounds fine, but then it seems like 50 different service request types result in a mess of properties that would all show in all 50 types of service request.

Is there any way to be able to get a different look for each type of service request?  What am I missing?

Adrian_Paech

Personally I'm still a bit confused why you would use inhereted classes in this case, but maybe I'm confused about the use case.

Where form based extensions cannot be concatenated as part of multiple MPs, class extensions can be concatinated. For example, we have two seperate MPs that extend the SR class with no issues.

if you want to display different portal forms for different groups of users, you can control this via the admin settings in the portal, and by modifying servicerequest.js

See:
https://support.cireson.com/KnowledgeBase/View/1174#/

And:
https://support.cireson.com/KnowledgeBase/View/51?selectedtab=enduser#/

Hope this helps. Adrian

Dan_Metzler

Let me clarify a bit...
Let's say we need to create a couple service request/request offerings.
1) Request to build a VM that contains about 10 fields/properties related to new VMs.
2) Request to have a new Share created on a file server with a couple fields/properties that include share name, and maybe a group name to add to permissions.

If you extend, any Service Request has all properties for all of those types of requests.  Now scale that out to 50 types of service requests.
So then when looking at forms, I'm looking for a way that customers only see the fields related to the type of request they are submitting.  (So on a request to create a share, they don't have to think about "

If you extend, how do you avoid exposing a big mess of random fields once you have many types of requests?
Whether you extend or inherit, how do you avoid the same issue when customizing forms in the Cireson Portal?

I checked out both links, and kind of see how you can tie a form to a type projection, and how you can customize the "ServiceRequest" form that a user will see in the portal.  However, it still looks like any given user is going to see the same form with the same properties, whether you are looking at a "VM Request" or a "Share Request".  The more types of requests you implement, the more you have a bunch of unneeded fields on a form that don't relate to 1 type of request that the user is focused on.

Adrian_Paech

We have similar requirements for "New Staff Member" Creation, "Hardware Request" and many others.

But in these scenarios, we just dynamically build out the contents of the description field, and each underlying activity description field to specify what is required.

This minimises the need for creating additional fields (extending classes).

We have extended the IR class quite a lot to cater for major incidents / post incident reviews etc, but this is a special case.

Also, we have avoided using enums, and use additional classes instead. This ensures you don't have to extend the SR class to be able to link related information to the SR. Instead you can just link the CI to the SR, which does not require additional fields to be extended on the class.

Hope this helps.

Regards,

Adrian

Dan_Metzler

Ok.  I'm interested in following that line of thought.

Can you give an example of what you mean by "dynamically build out the contents of the description field"?

What are you doing with the underlying activity description field?

Are the description fields parsed somehow by SCORCH automation, or are they just there to provide a human readable display of the request?  Do customers enter data into the description field?  Is it structured, perhaps using something like a JSON structure?

Regarding your strategy for avoiding enum lists...  Are you saying you derive/inherit a new class from Configuration Item class, and maintain any lists that way?

Thanks very much for your insights.

Geoff_Ross

Agree with @Adrian_Paech here.
To answer some of your questions @Dan_Metzler, 

You can use the Multiple Mappings feature of the Cireson Advanced Offering to map many or in fact all of the users prompt answers into one field.

So you can make your Description field read:

This is a request for access to <Which folder do you need access to?> and the reason for the request is <Please enter the reason you need access>. 

The Advanced Request Offering feature will fill in the placeholders with the actual answers the user provided.

In terms of them automating this request, I wouldn't try and parse that description to grab that values. I treat description as the human readable field and I also map all inputs to a computer readable field - usually a single extended property - in either JSON or XML format. eg

{"Folder":"<Which folder do you need access to?>","Reason":"<Please enter the reason you need access>"}

Again, once the real inputs have been injected, this can be read into the runbook.

Finally, yes, custom CI Classes, based on the 'Base CI' class can be used for these kind of 'pick an item' type prompts.

Geoff

Adrian_Paech

For the "Dynamic Building of the Description Field":

I'm using a combination of Cireson Multiple Mappings (as part of Ciresons advanced request offerings) and some post work-item creation workflow processing. The workflow essentially looks for and processes any custom "IF" block tags which then break out and only display the relevant fields I need depending on what the user has selected within the form.

Once the RO is logged multiple mapping fields are not applied to the description field, but instead to a custom additional extended field called "DescirptionTemplate". After being logged, the custom workflow runs. The workflow auto-runs whenever a new work item is created. (of any WI class type). The wokflow runs a powershell script on the SCSM server, which imports a custom written module and then calls a function called "Update-SCSM-WIReferenceFields -computerName $computerName -objWI $objWI"

This is a custom function which essentially looks for the contents of "DescriptionTemplate". This field contains the jiberish (shown here: https://community.cireson.com/discussion/1290/ro-multiple-mapping-dynamically-builds-text-based-on-form-selection-criteria#latest ). Update-SCSM-WIReferenceFields reads this jiberish, processes the IF Block contents, and then places the result into the description field.

Here is an example result from a 60+ field multi page complex Advanced RO:

[ Requested For ]
--------------------
Multiple Staff:
    Jonathan Lambert, Carolyn Lam, Kevin Lamon

[ Sharepoint Access Requirements ]
---------------------------------------
Sharepoint Website:
    http://TheLastTestWillWork.com
Access Required:
    Contribute

[ Other Special Requirements ]
----------------------------------
Some Special Requirements

[ Required By ]
-----------------
Date: 10/11/2016 00:00
Justification for 'Urgency':
    Its Just urgent!

[ Business Justification ]
---------------------------
Some Justification

[ Approval ]
--------------
Request Approver: Ingrid Ahmer

----

We then use <pre> </pre> tags to display this in the e-mail we send out to users / analysts etc.

You could do something similar using SCORCH, but I find its a bit to slow to process, so prefer to use workflows for these types of scenarios.

For "Regarding my strategy for avoiding enum lists"...

Yes, I use classes to create lists, instead of Enums. They are much easier to maintain via powershell, And although the cireson CI picker is currently a bit clunky within request offerings, Cireson have indicated that they will soon be releasing a new and improved picker. I also wrote some custom JS to improve the functionality of the curring CI object picker if your interested.

https://community.cireson.com/discussion/1167/download-improve-ui-on-request-offering-grid-picker#latest

Hope this helps clarify a few things.

Regards,

Adrian

<p><br></p><p><br></p><p><br></p><p><br></p><p><br></p><p></p>

Adrian_Paech

Geoff,

For interest sake, Would it be possible to do something similar to what I have mentioned above on the fly with JS on the portal once the RO has been created? Or would it be much more complex to process?

Regards,

Adrian

Geoff_Ross

Nice @Adrian_Paech

That's like what i'm doing but up another 6 levels!!! Very cool.

As for doing it in the Portal - maybe.

You could certainly do it on the first open of the SR, so description would be blank until someone opens that SR and then the code would run to process the DescriptionTemplate and fill Description. This would be quicker than the page can load so you wouldn't see it be if someone used another method to access the SR first, (Outlook Console) then Description would still be blank.

I can't think off the top of my head a way to trigger this on creation of the SR (other than have code running on every page load which grabs all SRs with blank description and processes them - which would be inefficient).

As for your Picker customisation - I also love this, very nice. Yes, Cireson are also working on a new picker but no ETA on that yet. Anyone who found the bug in v6.0.2 might have had a sneak peak at it.

Geoff

Adrian_Paech

Thanks Geoff.

Yea its probably not worth trying to do is when the analyst first loads the SR, as we need to have it ready to go for when we send out initial e-mail notifications.

I was thinking that maybe there was some way to intervene at the point the SR is being saved (by the end user).

But I would have no idea where to start.

For now though, I'm happy with the workflow / powershell approach

Cheers,

Adrian