Extending sc_req_item, how do I map the catalog?

[tahnalos]

We have a bunch of Catalog Items in the Service Catalog that are going to be sent to a wide variety of integrations.

Normally, I would have been ok with just using variables, but the issue here is that these integrations are not able to read anything within the sc_item_option and sc_item_option_mtom tables.   A repository table would have been an option, but given that these items ask different questions, the repository would have to have a lot of columns.

A suggestion was made to extend the sc_req_item table to include the data for each of these integrations so that it can still use the data from the Request Items table itself, which is great and everything, however, I am unable to set up the catalog item to map to the extended table.   Anyone have any idea on how I might do this?   Using variables would be one option, but I would prefer to stay away from accessing variables if at all possible as it means that if the columns in the extended table change, the code that uses the variables has to be reset.

Ideas anyone?

[Tim Woodruff]

I'm afraid that this doesn't include enough information about the nature of the problem (for example, why aren't you able to do some of the things you mentioned above?) for me to be of much help, but perhaps you can package all of the variables into an object as properties, and present the object via a script to whatever needs to view them? That way you can - on the integrations' side - just for-loop over the object's properties to get the name and value of each of the catalog variables.

[Brian Dailey1]

Hi Tahnalos,

Here's one solution for you to get those catalog items generating tasks in your custom extended table (extending [sc_req_item]).

1. Create your custom table extending [sc_req_item], for this example [u_extended_req_item].
2. Select the "Autonumber" option and setup your numbering scheme for the table.
3. Using either Form Designer or Form Layout, add the existing field 'meta' to your Catalog Item form if it is not already displayed.
4. Enter a unique value in the 'meta' field to identify your specialized Catalog Items, (e.g., 'ext_req_item')
5. Create a business rule on Requested Item [sc_req_item]:
   When: Before, on Insert
   Condition:       Item.Meta contains ext_req_item
   Script:

function onBefore(current, previous){

current.sys_class_name = 'u_extended_req_item';

current.number = getNextObjNumberPadded();

}

That should do it... it will catch the RITMS created by ordering from the catalog before insert, and change their task type to your custom table extending [sc_req_item].   I've setup a simple test scenario and it seems to work fine.   Give it a try.

Thanks,

-Brian

[tahnalos]

Timothy, there are two reasons why I cant use a join of sc_item_option and sc_item_option_mtom.

The first approach was to basically have each record be a question and answer pair with a reference to the RITM.   It was discovered that this would not work as the integration doesn't know how to get proper display values for each question, and therefore the question would need to be saved as text.   This would fail if the questions were localized.

The second approach was to have all the answers in different columns so that the integration can properly get all the answers, but the problem with that approach is the integration looks at only one table, and that there are multiple catalog items that we want to present to the integration.   We would have to jam about 30 fields in the table (about 10 per item), and there could be more down the road.   In other words, extensibility is an issue.

The idea to extend the sc_req_item table works because the integration can be pointed to the sc_req_item, and a subset can be set up to handle the extended tables.   This integration is rather finnicky but we have been told that it would work if the sc_req_item table is extended.

Brian, I will look at your response.

Thanks

[tahnalos]

An update.

I recognize that I cannot get away without saving any variables in sc_item_option_mtom, so yes, I will have to leverage the variables to populate the extended table. The problem now lies in how to code the relationship between variable and field in extended table. How would a business rule running on insert of sc_req_item refer to its variables?

Ideas?