Highlighted
Absent Member.. Absent Member..
Absent Member..
386 views

User Selections to Interaction oddity

Jump to solution

First slight preface: we are attempting to bypass the shopping cart in our catalog, as we only allow one item to be ordred at a time anyway (for a variety of reasons). This means that the entire cart process (add to cart, select cart, submit cart) is unnecessary. We have modified existing request types to process as 'non-cart' items (bypassing the cart and going directly to submit). This is what the apparent purpose of 'one click' is.

However we have encountered something odd:

User selections are not populating on the subsequent interaction, however they DO appear as expected on the line items that are ordered.

So, in this example the user selection 'Printer Name', 'ASDF123' is filled out on the request and the cart is created (this happens in non-carts as well, via svccartitem table). The data is held in the 'options' field, which, according to the connector should go across per this line in the js tab :
if (options in $L.cartItem~=NULL and options in $L.cartItem~="</form>") then (svc.options in $L.file=options in $L.cartItem)

what I get however in the interaction.svcoptions field is just the fields, without their data (so I get an empty field labelled 'Printer Name', but not the corresponding data. The line items show the full setup, 'Printer Name','ASDF123' etc.

So it leaves me pretty puzzled since I was operating under the belief that the quote got its info from the interactio, but it appears to be getting it directly from the cartItem

Anyone have any thoughts on where breakdown is here? it seems to be somehow tied to the bypassing of certain cart steps (add to cart, checkout).

0 Likes
1 Solution

Accepted Solutions
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User Selections to Interaction oddity

Jump to solution

Well it wasn't the most elegant solution but it seems to work fine.

I ended up updating the trigger: after.incidents.update.screlate (JavaScript tab)

 

var usbcart = new SCFile("svccartitem");
if (usbcart.doSelect("cartId=\""+record.cartId+"\"") == RC_SUCCESS)
{
record.svc_options=usbcart.options;
}

The good thing is, this stuff is specific to the catalog process so at least there is that. Interestingly I found out that the catalog connector, as it is tied to OCMQ, updates the user selections (svc.options) directly in the quote. I had initially thought that the information was directly sequential from the svccartitem > interaction > quote > ocml.

It appears that the ocmq and interaction (incidents) steps are simultaneous, and the ocml spawns (naturally) off of the ocmq. SCrelate does all the heavy lifting between the ocmq and interaction from there on out. Still not entirely s

View solution in original post

0 Likes
3 Replies
Highlighted
Acclaimed Contributor.
Acclaimed Contributor.

Re: User Selections to Interaction oddity

Jump to solution

You didn't mention which version of Service Manager you use, but I tested your scenario in SM 9..34 (patch 4). I assume you used "old" ESS ordering mechanism, not new SRC.

I had no problems getting User Selections to SD. I used Service Catalog > Non-cart Catalog Request. So can't unfortunately say what's wrong in your system.

 

---
Moving on, this account is no longer active. Best regards, Kelalek
- So Long, and Thanks for All the Fish
0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User Selections to Interaction oddity

Jump to solution

Yes, 9.34, and good call on the classic catalog choice (we found SRC performance was not reasonable in our environment, so we have used the classic model instead).

I was afraid that it had to do with our customizations, and that appears to be the case. What I am attempting is somewhat unusual, using the normal ording process (with line items etc) via the non-cart path, which conceptually seems to implyI  that doesn't include OCML. Interstingly it does work, fairly well outside of this quirk. And honestly if approvals weren't done on the interaction it probably wouldn't be an issue since it's working fine on everything down from the quote (ocmq and ocml both get all their line items parsed just fine, which is good since I have backend logic tied to those fields).

Currently I am trying to force the triggers to overwrite svc.options with the svccartitem options field, but I don't appear to be hitting the record late enough.

Might have to do some weirdness with the incidents format control at this stage.

0 Likes
Highlighted
Absent Member.. Absent Member..
Absent Member..

Re: User Selections to Interaction oddity

Jump to solution

Well it wasn't the most elegant solution but it seems to work fine.

I ended up updating the trigger: after.incidents.update.screlate (JavaScript tab)

 

var usbcart = new SCFile("svccartitem");
if (usbcart.doSelect("cartId=\""+record.cartId+"\"") == RC_SUCCESS)
{
record.svc_options=usbcart.options;
}

The good thing is, this stuff is specific to the catalog process so at least there is that. Interestingly I found out that the catalog connector, as it is tied to OCMQ, updates the user selections (svc.options) directly in the quote. I had initially thought that the information was directly sequential from the svccartitem > interaction > quote > ocml.

It appears that the ocmq and interaction (incidents) steps are simultaneous, and the ocml spawns (naturally) off of the ocmq. SCrelate does all the heavy lifting between the ocmq and interaction from there on out. Still not entirely s

View solution in original post

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.