Extending Classes - Best Practices

Jarrett_Faulk

Hello Cireson Community,

I was watching the videos on automation and discovered that inherited classes are not technically supported in the self service portal.  Is this still true?  

Could anyone point me to some documentation on the best practices for extending the base classes such as the service request and incident request?  I've been going through google and the only information I could find was on Technet.  I'm hoping to find something a little more in-depth and maybe with some examples.

Thanks in advance.

Jarrett

Nicholas_Velich

Hi Jarrett,

Inherited Work Item classes are not really supported in the Cireson Portal. They will work for the most part, but you will run into some snags. For example, there is only one "Incident.js", "ServiceRequest.js", "ChangeRequest.js", "ReleaseRecord.js" and "Problem.js" file per out-of-box work item type-- when you have multiple children of any of those particular classes, you cannot really interact with the different child-level properties/relationships as you might like.

Inherited Configuration Item classes work just fine.

Extended classes work much much better, and are tested/supported fully. For a walk-through of how to extend the Incident class, check out this webinar here: https://community.cireson.com/discussion/30/creating-new-lists-for-the-portal-start-to-finish#latest

In short, the webinar walks through adding a new enum list to the Incident class, and ultimately getting that list into the Portal. The same logic can be used to add additional extended properties, such as Strings, Integers, Dates, etc.

Thanks,
Nick

Nicholas_Velich

Hi Jarrett,

Inherited Work Item classes are not really supported in the Cireson Portal. They will work for the most part, but you will run into some snags. For example, there is only one "Incident.js", "ServiceRequest.js", "ChangeRequest.js", "ReleaseRecord.js" and "Problem.js" file per out-of-box work item type-- when you have multiple children of any of those particular classes, you cannot really interact with the different child-level properties/relationships as you might like.

Inherited Configuration Item classes work just fine.

Extended classes work much much better, and are tested/supported fully. For a walk-through of how to extend the Incident class, check out this webinar here: https://community.cireson.com/discussion/30/creating-new-lists-for-the-portal-start-to-finish#latest

In short, the webinar walks through adding a new enum list to the Incident class, and ultimately getting that list into the Portal. The same logic can be used to add additional extended properties, such as Strings, Integers, Dates, etc.

Thanks,
Nick

Jarrett_Faulk

Thank you for the link to the webinar it was very informative.  This has however created some other questions.   The first being are there any limits to the number of properties that can be added to a class?  As the number of properties increase can I expect to see any decrease in system performance?  So far I have identified 6 request offerings that will be built off the service class which is going to require around 20 or 25 new properties to capture data.  

Thanks again for all the information.

Nicholas_Velich

Hi Jarrett,

With an enormous amount of extended properties, you could begin to see some performance issues in a larger environment. Try not to go above 20-30 or so if you can help it-- the fewer the better.

I should also note that the "Advanced Request Offering" feature of the Cireson Portal removes the need for a 1-to-1 mapping of "Request Offering Question" and "Property." With Advanced Request Offering, you can map multiple Request Offering Questions/Answers to a single property, and even format them in a user-friendly way.

Thanks,
Nick

Jarrett_Faulk

Hello again everyone,

By following all of the advice I've received here and the video i was able to reduce my custom properties down to 3 from 25.  I was able to import the management pack, create the unsealed management packs and build out the lists.  While I was creating a custom request offering I ran into another error.  One of the custom lists is used twice to gather user input.  I can configure the two prompts to use the list but when I attempt to publish the request i receive the attached error.  I was able work this problem down to where if i use the list one time, utilize it in the multiple mapping and set it to map in the Map Prompts window the error goes away.   As soon as I add the second instance of the list the error returns.  I assume that service manager is unable to recognize that list is used twice.  I believe the screen shot shows were the error is originating from but I have been unable to figure out how to overcome the issue.  I feel that this is something that should be able to be done, hopefully.

Does anyone have any suggestions?

Thanks in advance.

Nicholas_Velich

Hi Jarrett,

It looks like you have the out-of-box "Map Prompts" section pictured there rather than the "Multiple Mappings" feature of Advanced Request Offering. When I mentioned you could map multiple answers to a single String property, I was referring strictly to the Multiple Mappings section. Have you tried mapping the answers there?

Thanks,
Nick