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?

[tahnalos]

Interesting.

The workflow has now completed all the way through.   Not sure why.   However, as I mentioned earlier, the workflow was custom made so it would not surprise me if someone inadvertently coded a few gotchas in there.

Also, I can't view the workflow from the custom table (show workflow shows "no active contexts").   I have to look for it in active workflow contexts.

Thanks

[Brian Dailey1]

There ARE no (ok, precious few) mysteries left if you delve deep enough...

The most likely culprit is that the workflow was not being started because the custom RITM's stage was not being set as required by the conditions (... && current.stage=='request_approved'...) on the "Start Workflow" business rule.   Manually setting the approval to "Approved" resulted in the stage being updated (probably by another business rule) and kicked off the workflow.

As for showing the workflow, you can't see it because the UI Action "Show Workflow" is using the sc_req_item table specifically:

                  var url = 'context_workflow.do?sysparm_stack=no&sysparm_table=sc_req_item&sysparm_document=' + id;

The most basic mod is to create a version of this UI Action (Show Workflow) for your custom table that uses the correct table name.   Or you could instead adapt the existing UI Action's script to dynamically insert the correct table name:

                  var url = 'context_workflow.do?sysparm_stack=no&sysparm_table=' + g_form.getTableName()   + '&sysparm_document=' + id;

Either way works.

Thanks,

-Brian

Edit:   Sorry, accidentally mixed some server-side coding in there.   Edited to use the client-side "g_form.getTableName()" instead.

[tahnalos]

Brian, thanks for all your help.

With these issues, it has become clear that this effort is not being fruitful as I had hoped.   There are way too many modifications required for this to work, and the integration in question is not as link-friendly as I thought it would be.   We will be re-examining this ask and hopefully we can come up with a better alternative.   One thing I would make clear is that there is a reason why some people have mentioned privately to me that extending sc_req_item is a recipe for headaches and disaster if not done correctly.

Thanks

[Brian Dailey1]

No problem.   And don't fear making changes, just make sure you understand what it is your changes do...

It goes back to the Legos, when you look at them all assembled it can seem quite complex, but it's really just a series of simple blocks put together.   The trick is in understanding which blocks you need to use and where to put them.

-Brian

[Daniel Oderbolz]

I know this is an old Thread, but still.

I think you are looking for record producers.

These are a special kind of catalog item that crerates records in tables.

Best
Daniel