CA Service Management

HI! I'm deploying CA Catalog 14 and I'm having trouble to export the information of the selected items selected in the offer to the Service Desk request. Is there a way to copy it without using PAM?

Thank you!

Sebastian

Good Morning Sebastian.
 
If I understand this correctly:
- You have a CA Service Catalog(SC) service option (with a form).
- In SC, you open a request for this option.
- Then you want to retrieve the data of the request(and it's form) to update an existing or create a new SDM-request.
- And this without the use of PAM.
 
To be able to accomplish this, you could then decide to make use of the Event-Rule-Action(ERA) functionality in SC.
The action can be of 'type=java'. Through which you can spawn/execute a java process.
 
You can also check this on the next page:
https://docops.ca.com/ca-service-management/14-1/en/using/service-catalog-management/manage-events-rules-actions
And see the 'Actions' section in there.
 
Kind regards, Louis van Amelsfort.

Hi Louis, thank you very much. The process is just as you described, and i am also using the default event that calls this java class: com.ca.usm.ruleEngine.action.sdm.CreateIncidentAction

With the use of that class the SDM request is opened correctly with the information of the form but without the the names of the service options selected. Do you know if i have to add another class or is just a variable or a javascript in the form?

Best regards!

Sebastian

Good Morning Sebastian.
 
Thanks for your reply and good to hear, things work okay(although partly).
 
As to your question about 'the names of the service options selected', I found the following:
You can see a similar, ootb definition in:
SC>Administration>Events-Rules-Actions>Request/Subscription Item Change>When Category is Service Management Content and Status is Pending Fulfillment
Rule  : When Category is Service Management Content and Status is Pending Fulfillment
Action: Create Incident/Java
Java Class: com.ca.usm.ruleEngine.action.sdm.CreateIncidentAction
 
And I do not see any other details in there.
 
For an SDM-Incident created, I see in the SDM-Incident itself:
External System Ticket = CASC-10392-10075(SC-Request_id).
No reference though the the name of the service(option).
 
And for an SDM-ChangeOrder, the same is seen:
External System Ticket = CASC-10394-10076(SC-Request_id).
 
With this said, as far as I can searched for and see happening, the name of the service(option) is not being recorded as such.
 
May be 'other' people in the community can help you further.
 
Thanks again and kind regards, Louis.

If you want to use the java class, you can always create two new textbox in your forms and hide them.

You can set value to JS variable that contains service name and option item text.

The java class should grab them and add them to the SD request description.

I've personnaly never tried the java class and i don't think my solution is elegant, but it should bring you where you want.

Perhaps someone with a better knowledge of the java classes will have a more appropriate solution.

Hope this helps.

The field set before i hide it

Field set attribute :

Service name attributes :

Option name attributes

Hi, thank you very much for your answer!

I tried your solution and it seems to be the one but when i started to test it i found a problem:

When i have only one option in the group the variable works fine:

When i have two options in the group  the variable only takes the last option:

Any idea to fix this?

Best Regards

Hi Sebastian,

I've always used pam along with catalog so I'm unfamiliar with the java classes you're using in SD, but I do have an idea that you can implement within the catalog form itself to continue to allow the Java class to retrieve a single field containing multiple values from the catalog form.

Within the script box of the catalog form you could retrieve the values from both visible fields, concatenate the strings together, then put them in the one hidden field you already use before you call the Java class from SD to retrieve the values.

There's an example on lines 128 - 139 of the attached file, (I personally wouldn't recommend naming a function 'x' but apparently someone copied the example and didn't change it ) or if you prefer easily scale-able solutions you can find an example of a for loop within a function on lines 9 -20 that you can use to retrieve values from many fields.

Disclaimer: You can write alot of powerful JavaScript within the catalog forms, but it does come with it's cost in terms of load time for your catalog forms.

Happy Scripting

Elwynn.

Hi! Thanks for your answer. I believe this solution applies to a selection object inside the form, am i right? Because i need to export the selection of the elements inside an option group, in fact, the articles that the user want to request in the offer.

Best regards

Sperna,

Yes this applies to retrieving the values of the fields on the form, rather than passing the entire collection of fields to either SD or PAM whether they have a value in them or not. Doing that requires using the getFormRateItemValues method in the Cat. WSDL.

Elwynn.

Hello,

In your exemple, do you use the same form for both options? Have you tried a 2nd form with different ID names for the hide text fields?

Hi! Yes i'm using the same form for both options, but i also tried differents forms with the same result.

Ah sorry, sorry ... we only use PAM to process requests from catalog to service desk. I took a chance to perhaps help you;)

Thank you anyway! It seems like i must use PAM.

I have to check if there are default processes without creating a new one...

Sperna,

Are you using two fields with the same id either on the same form or different forms? I could see duplicate ids giving you some problems.

Also I couldn't quite tell if your screen shot above is of one form or multiple forms under the same service option?

If you are using separate forms under the same service option in Catalog, PAM will read them as having different form ids and I would assume the Java classes would behave similarly. In that case you may be able use duplicate field ids but you would need to account for the separate forms.

Elwynn.

Hi Elwynn! Many thanks for your help! I really appreciate it!

I'm using the same form for different service options. I took some screenshots:

This is one form with a unique ID:

It has 2 textbox with uniques IDs:

I have 1 Option Group with two products (with multiple selection available). Both products use the same form:

The idea is to avoid PAM for three reasons:

- We don't have the skill to create processes in PAM

- We want to keep the solution really simple so its easier to administrate and upgrade

- We want a fast process

Best Regards

Sebastian

Sebastian,

You're welcome! I enjoy the challenge of fresh problems and learning new things

I looked at the example Pier-Oliver gave back on the 6th and discovered that you maybe able to use a combination of the values accessible through the _. and javascript to solve your problem. If you can determine which service option called the form using the _. information, then use javascript to populate hidden text boxes that the Java class is retrieving it's data from, you maybe able to retrieve the values users have entered as well as the service option they used to call the form and pass it all into SD.

Am I understanding you correctly that you want to use a single form for all 3 service options?

Elwynn.

Hi Elwynn, the problem is that i don't find a value stored in a variable (_.) that brings the information that i need. The one that it is supposed to do that is _.soe.item_text but it has a bug when you have more than 1 service option.

Yes I want to use the same form for all 3 service options because i aim to have just a few forms.

Sebastian

Hey Sperna, i was out of office, sorry.

I do not have an answer for you but i'm sur my boy Jason_Wolfe will be able to guide you

Personnaly, it looks like a bug to me. Pretty sure it has something to do with the JS Context / Scope.

To Jason : I can understand JS Scope having issues when you have two forms in an option, but having issues accross several Options? 

At quick glance this does appear to be a bug and would suggest raising a case with Support for further review.

As for a somewhat quick, albeit dirty workaround you could use two forms and leverage getDocumentById to get the first service option name similar to the following:

1) Create a copy of the form, change the form _id and associate to the second service option

2) Navigate to the offering from Home > Requests and grab the html id of the first service option name by inspecting the element using the browser console (shift+ctrl+i in Firefox/Chrome) similar to the following:

3) Instead of using the JavaScript expression _.soe.item_text for the first service option name, create a JavaScript function in the Script dialog of the first form to invoke onLoad similar to the following:

setOptionName:function(){

var htmlSO=document.getElementById('row_1_21858').getAttribute('item_text');
ca_fdSetTextFieldValue(ca_fd.formId,'txtf_11',htmlSO);
}

Note: You will need to replace 'row_1_21858' and 'txtf_11' with the html id from step 2 and your text field _id, respectively.

4) Update the onLoad attribute of the first form similar to 'ca_fd.js.setOptionName()'

5) Remove the JavaScript expression $(_.soe.item_text) from your first form's text field

Hi Jason, thank you for your response. 

I tried your solution and I discovered the reason why it is not working! The error is when i use it through USS. 

When i try it through USS i get this error: Error while invoking onload function: ca_fd.js.onLoad(). You can see it with the text box called by script that it is not filled and with the textbox by variable that uses the soe item text variable (with the mistake of filling with the wrong information)

When i try it through Catalog your script and the $(_.soe.item_text) works fine!

Do you think that it is an USS bug? Should I open a new case with Support?

Best Regards,

Sebastian

Good Morning Sebastian.
 
It is known that from within the USS-UI, Catalog-Form-Scripts are being executed differently than from within the SC-UI itself.
 
A way to overcome this is the following.
 
Service Catalog provides a method to create your own custom JavaScript functions in a central location.
Which is USM_Home\filestore\custom\explorer\scripts\custom_form_lib.js file.
Which means that these java functions can be called from multiple forms and from multiple places.
This is very useful for reducing maintenance for common functions.
 
This might avoid getting the error that you received.
 
Custom js file:
function mytest() {
alert(2);
}
 
Form:
onLoad = mytest()
 
Thanks and kind regards, Louis.

Good Morning Louis, thank you for your response! I tried your solution but I still got this message:

Error while invoking onload function: mytest()

This is what i did:

I added the code to the custom_form_lib.js file

In the form I configured the OnLoad function

Is that right?

Best Regards,

Sebastian

Do you recycle Service Catalog? 

Good Afternoon Sebastian.

Yes, that's right. And do not forget to recycle the SC-Service, after you changed the .js file, right?

Kind regards, Louis.

Yes, I restarted the Windows Service of CA Service Catalog, is that enough?

Normally yes, the catalog hides the forms to allow faster access ...
normally when you restart the service is enough.
Make sure that your browser cache is also emptied. 
If you can not see changes to your form every time you make changes,
 you can apply the following doc in your DEV environment.

(Https://www.ca.com/us/services-support/ca-support/ca-support-online/knowledge-base-articles.TEC1943332.html)
You will be certain that no cache will be there.
By default, the catalog keeps the forms cached for 24 hours.

Great, now i get the right message: "2"

Sorry for my lack of knowledge! Now that I get that message right, do I have to use my script to fill the text boxes in there?

I tried with this code in the custom_form_lib.js:

function SetItemText() {
ca_fdSetTextFieldValue(ca_fd.formId,'txtTEST',_.soe.item_text);
}

In Catalog works fine but in USS don't.

Just an update. The variable doesn't work on USS so CA is working in a fix for it.