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?

[Brian Dailey1]

Hi Tahnalos,

I do not think you will be able to use a business rule before insert on the table that can access the item's variables in order to alter the record before insert.   The reason being:   that if a field in a table (e.g., [sc_item_option_mtom].request_item) is going to refer to a record in another table (e.g., [sc_req_item], or your custom table), then that record MUST exist first to establish the reference.   In other words, you have to let it save your record first before accessing the variables.

Some options for you would be:

1. to add another BR that runs after insert to update whatever fields you need based on variables that get related to this item (even though you generally shouldn't update a current record using an After BR, you could do it and include 'current.setWorkflow(false)' to prevent other BR's from running again),
   
   or
   
2. setup a workflow for this type of item that does something similar using a Run Script activity.

Make sense?

-Brian

[tahnalos]

A run script on a workflow might work.

After testing this out the biggest problem at current is that the record is created at the sc_req_item level, and not at the extended table level.   Any ideas on how I might "spread" the base Request Item definition to the extended definition?

Thanks

[Brian Dailey1]

Hi Tahnalos,

Ok, let me first explain how extended tables work.   Extending a table is like adding another Lego block to an existing Lego structure... you still have the original structure, but with a small change added.   However you don't have a new copy of the structure, only the original with something added.

Extended tables work in a similar fashion.   When you extend the Task table to create the Incident table (or Request, Problem, Requested Item, etc.), the extending (child) table holds the additional structure, but the base (a.k.a., parent, or extended) table still contains it's portion of that extended record.   If you look in the Task table (try typing "task.list" into the navigation filter), you can see every type of task represented in the field labeled "Task Type".   You will see REQ/INC/RITM/etc. records listed, and the task type displays the name of the child (extending) table that the record belongs to (i.e., incident, sc_request, sc_req_item)

This Task Type field is actually named 'sys_class_name', and you will find it in every table that gets extended.   Because the Requested Item [sc_req_item] table is extending the Task table, when you save that RITM record it is being saved in the Task table and setting the value of sys_class_name = 'sc_req_item' to identify which child table it belongs to.

So... now on to your dilemma.

1. First, use my original solution of placing a BR to run on the [sc_req_item] table Before Insert.   Have it check for the condition "Item.Meta contains <your_special_value>".   The BR's script then changes the value of *sys_class_name* to be the name of your custom table which is extending [sc_req_item].
   
   *THIS* is how you change the RITM being created by the catalog ordering process into one of your custom task objects instead.
2. Next, use either a Workflow or an After Insert BR on your custom table to gather the data from your variables and update values on your custom task to be used down the line.

When ordering from the catalog, you can't change that it creates ordered items in the [sc_req_item] table without implementing custom Cart ordering functionality.   I think that's more customization than you really want to do.   However, you can use this BR setup to catch the record before it gets written and change its type to the extended table you've created.

Hopefully that makes sense.   Give it a try.

Thanks,

-Brian

[tahnalos]

Thanks Brian.   I misinterpreted your initial answer and didn't quite understand it.   It also didn't help that I entered the script incorrectly.

Is there any other use for the meta field?

[tahnalos]

An even bigger problem:

There are several workflows that are used by the Catalog items we are modifying for use on the extended table.   They are no longer working.   Moving them to run off the extended table also does not work (it's stuck at the begin stage).

Is there something I am missing here?