Bypassing Service Catalog Checkout UI via Record Producers

[Christopher Cro]

Overview

Let's say you're building a Catalog Item for your Service Catalog. You need it to be a Catalog Item, because you want to use workflows, but you really don't want to be forced to use the Checkout UI. Perhaps you're using the two-step process and that's just too much for your particular needs with this particular item.

In these cases, you might be tempted to use a Record Producer to crank out the RITM directly, but, if you've attempted this, you've probably realized that it breaks the associated workflow! So, how do we work around this issue? How can we get the catalog item to behave as if it was created via the cart without having to deal with the forced UI?

Solution

Simple! We just need to invoke the CartJS API to spawn the Catalog Item's RITM from within the Record Producer's script. You build out the Catalog Item as usual, then you create a "shadow" Record Producer with exactly the same variables. This "shadow" Record Producer will serve as the front-end that replaces the Checkout UI, it just serves to provide input fields to the end user before it hands off that data to the Catalog Item at the time of creation.

Here's what that looks like from the Record Producer Script (remember to swap in your own Catalog Item id & variables😞

// Abort the record that would be produced by a normal RP
current.setAbortAction(true);
// Set up a new Cart
var cartId = GlideGuid.generate(null);
var cart = new Cart(cartId);
// Insert the Catalog Item into the cart
var item = cart.addItem('[CATALOGITEMSYSID]');
// Transfer the variables from this producer to the new RITM
// NOTE: You will need to edit these setVariable lines to match your own variable names
// One line per variable, so add/subtract lines as necessary!
cart.setVariable(item, 'account', producer.account);
cart.setVariable(item, 'location', producer.location);
cart.setVariable(item, 'fields', producer.fields);
cart.setVariable(item, 'correct_information', producer.correct_information);
// Submit the order and generate the RITM
var rc = cart.placeOrder();
// Override the "Redirect To" setting to go to the new RITM
producer.redirect = rc.getLink();

Explanation

Note how we're not doing very much here. All we're doing is taking the variables filled in on the RP page and transferring them to a new scripted order containing our catalog item. That's why it's important to have the same variables in both the Record Producer and the Catalog Item. If it were missing in the Record Producer, the user wouldn't have any way to fill it in. If it were missing in the Catalog Item, the Record Producer would have nowhere to put the user's input. You could think of this whole Record Producer business as just setting up an alternative "Front End" to the Catalog Item.

Once set up, simply make your Record Producer available within the Service Catalog (take care to hide the actual Catalog Item so that people do not directly access it!). The Record Producer should now kick off the RITM with working workflows without pushing the user through the checkout UI. By default, the above script redirects to the generated RITM (see final line), but this line can be modified to go elsewhere, if desired. Should you would instead wish to redirect back to the catalog homepage, simply remove the line altogether and make sure the "Redirect To" field is configured for "Catalog Homepage"

Additional Notes

If you're encountering issues where some/all variables in the produced RITM are missing, pull up both the Record Producer and the Catalog Item and compare their variables side-by-side. Make sure the variable names are exactly the same. After that, go back to the Record Producer script and verify there is a correctly written setVariable line for each variable you're using. For example, if I have a variable called "employee_age", I would need to have a line in my script that goes:

cart.setVariable(item, 'employee_age', producer.employee_age);

Technically, the variables in the RP and Catalog Item don't have to share a name, as long as the setVariable line is set up to accommodate that, but doing this has no real advantage and just makes the code a lot harder to understand. This might be desirable if you were to write a more complex RP that did additional work before generating the RITM, so do with that information what you will...