Jump to content

prohacx

Members
  • Content Count

    815
  • Joined

  • Last visited

  • Days Won

    1

prohacx last won the day on February 9 2016

prohacx had the most liked content!

Community Reputation

1 Neutral

About prohacx

  • Rank
    Level 7 Contributor
  • Birthday 06/06/1976

Profile Information

  • Gender
    Male
  • Location
    Belgium

Recent Profile Visitors

780 profile views
  1. Hi Manish, after each doSelect call you need to have an XMLExtraction operator in PAM that can take the input you have and extract it. For some bizarre reason Service Desk returns a non XML value (using lt; and gt; instead of < and >). This is why you need an XMLExtraction operator.
  2. I agree with Mitu, the Axis web services work against SDM objects. Afaik, there is no object that contains the logged in users, so there is no direct web service call to get that information. In such cases, you could consider writing your own (Spell) function and using the CallServerMethod web service to get what you need. (assuming you can figure out how to get the logged in users through a spell call, either trying to call the same daemon as pdm_webstat is doing, or by executing pdm_webstat on the server through your custom spell function and returning its output).
  3. A trigger like this should fire on ticket insert or impact update: MODIFY cr POST_VALIDATE z_assign_impact() 900 FILTER (EVENT("INSERT") || impact{} ); Your spell code should then look like: cr::z_assign_impact(...) { int new_impact; send_wait(0, this, "get_attr_vals", 1, "affected_resource.service_impact"); if ( !is_null(msg[3]) ) { new_impact = msg[3]; send_wait(0, this, "call_attr", "impact", "set_val", new_impact, "SURE_SET"); } } If you go with this object trigger as opposed to the attribute trigger you are using now then it would be a good idea to disable y
  4. The trigger you use is defined at the attribute level, meaning it only triggers when you update the impact field. If you have this code fire on ticket creation then that will also fire when you create a ticket through web services. Another way would be to first create your ticket through web services, then update the impact field using a web service call.
  5. You need to do one more XMLExtraction operator after your SOAP operator call to a Service Desk web service. This XMLExtraction operator will allow you to parse the content returned from the soap call and do whatever you want to do with it (like storing some values in the process dataset for example to use at a later stage).
  6. I don't know of any string_to_date function you can call in spell. Where did you see this? I guess worst case you will need to convert the string yourself into an int, then cast that to a date...
  7. I'm afraid that until CA comes up with a real multilingual solution we are stuck with form groups. Luckily Spanish is a supported language by CA (if I remember well) so you can get the files from them and use those.
  8. You can practically load anything into Service Desk. I don't have the exact file at hand for loading properties, but just make one property on one category and have your counterpart export it. Work from there. I would expect you will need to replace some category symbols with IDs or persistent_ids, but that should be straightforward (have your counterpart export category symbol and id, then use excel or so to do all necessary lookups and come up with your final file to load).
  9. Hi Stefan, I've been trying to follow along and hopefully help you out but so far I'm at the same point as you are: the browser seems stuck. Unless when I change the cfg content to zTEST zTest MODIFY READ or something, then at least I get an error on my browser screen too... Hoping to find some time later tomorrow to maybe find a solution...
  10. I would think you also need to make some object changes so that the NR object knows there is a zCIALG object linked to it to store those activities, then make sure your htmpl files work with that...
  11. Just updating after I reviewed my old question My initial question came from the fact that we wanted to load CIs (and relationships) into the TWA tables by a client side (custom developed) tool. The issue obviously then is how to also have it move data from TWA into the CMDB on command (as opposed to running a server side batch to call grloader at a scheduled time). Problem solved by now (since some time in fact...): we wrote a client side tool that uses web services to push data from an XML or CSV file into the TWA tables, then calls grloader on the server (also done through web service re
  12. I can see this: <Attribute DataType="2002"> <AttrName>zotherareas</AttrName> <AttrValue /> </Attribute> So your code should look more like: string[] attrVal = new string[] { "requestor", userhandle, "category", category, //"implementer group", impGroup, "impact", impact, //"sched_start_date", changeStartDateTime, //"sched_end_date", changeEndDateTime, //"environment", environment, //"ci family", ciFamily, //"reason", reason, "zotherareas", areas, "summary", summary, "description", description }; At least, that is if that zotherareas field is
  13. There are always ways to achieve things. A lot will depend on your process. Once the ticket is created in SDM, will it be a manual taks for someone to do the installation or do you want this install to be done automatically? When you say "user will see a list", then where do they see that? Is the action triggered from within MS CCM or some other way? Personally, I would consider this to be a sort of "Software installation request", implemented as a service in CA Service Catalog. With CA Service Catalog you can then specify an approval process (if required), create SDM tickets if needed and e
  14. EEM can only connect to 1 LDAP source, so I'm guessing you are connecting to a merged source with contacts from both domains in them. Like Mitu is saying: you'll need to find a way to get the data then formatted in a domain\userid format. That should then allow your users to log in. Also: EEM cannot handle SSO, so if that is one of your requirements you'll need to look for another solution. I'm interested to see if you get it to work (and how), keep us posted
  15. From a dark past I remember something with expand... try this: expand("abc>{test.txt}");
×
×
  • Create New...