Extra RITM being created

steverak · ‎10-21-2016

Hey all,

I've been beating my head against a wall on this for a few days now and haven't been able to find a solution.

I have an inbound action that will create a request and requested item(s) based on the email coming in. I have the logic working outside of the cart API to find the appropriate text in the email that should trigger ordering a particular item and kick off the workflow. However, I get an extra, mystery RITM that gets created with no catalog item associated (or anything else).

Here's the code where the RITM gets created:

function createRequestItem() {
   var grRequestItem = new GlideRecord ("sc_req_item");
   gs.log("RITM Created", "EMAIL." + sys_email.sys_id);
   grRequestItem.short_description = subject;
   grRequestItem.description = "received from: " + email.origemail + "\n\n" + email.body_html;
   grRequestItem.request = current.sys_id;
   grRequestItem.cat_item = 'Deployment Request'; //Both of these seem to be required to set the item properly
   grRequestItem.cat_item.setDisplayValue('Deployment Request');
   grRequestItem.insert();
   //Trigger the workflow for the catalog item
   var w = new Workflow();
wfSysId = w.getWorkflowFromName("Deployment Tasks");
   w.startFlow(wfSysId, current, current.operation());
}

I cannot figure out why a second RITM is being created that is essentially empty. I've tried using grRequestItem.initialize(); before setting any values and that doesn't seem to make a difference.

Thanks in advance.

steverak · ‎10-26-2016

Thanks for the help everyone! I was able to figure it out. It seemed to be a combination of how I was setting the catalog item (using the setDisplayValue and a regular assignment vs using the sys_id of the item being ordered) and the how I was kicking off the workflow.

Using the sys_id to set the item stopped the extra RITM from showing as "catalog item removed" and then getting rid of the workflow stopped it being created.

I'm still a bit perplexed as to why I was getting an extra RITM with this and not other places where I do the same thing to start the workflow. The best I can figure is that the workflow was triggering once with the setDisplayValue command, then again with the straight assignment, and then actually starting at the end of the function. Hopefully this will help someone in the future. I am calling this one good.

For everyone that recommended using the cart API, I have a few reasons why I don't: there's tons of information about the deployments we do that comes in the email and I would have to create extra variables for each type of deployment in the catalog (I know this is a bit lazy, perhaps I'll do it in the future), the other big reason is that this function is more reusable in the long run as I don't need to set individual variables for every catalog item when a new team wants to implement something like this or starts offering a new product.

Edit: Added some additional information on what I think was happening and why I don't use the cart API.

View solution in original post

ahaz86 · ‎10-21-2016

Doubt this is related to why youre having that blank one created btu what is going on in line 14? Where is that(wwfSysId) defined?

ahaz86 · ‎10-21-2016

Is this on an inbound action? If so what is the target table?

steverak · ‎10-21-2016

Oops, that was a transcription error on my part. It should read like this:

	var w = new Workflow();
	wfSysId = w.getWorkflowFromName("Deployment Tasks");
	w.startFlow(wfSysId, current, current.operation());

It is on an inbound action on the Request table. Essentially this is what happens:

-Email comes in with specific text that relates to a catalog item (there could be a lot of items here, so I want to be able to create multiple RITMs with different items and associate with the same REQ)

-Inbound action creates the REQ

-Creates RITM

-Sets ritm.request field to associate the two

-Kicks off appropriate workflow

Shawn Dowler · ‎10-21-2016

I know you probably already checked, but does your workflow create the extra blank RITM?