Trying to retrieve the changes for any application within an access change request in a suitable format so that it can be included in the XML payload for a Create Ticket webservice call.
We cannot use the OOTB ${access_request_details} variable as ...
- It includes HTML list tags
- It includes the entitlement alternate name (and we want the raw name)
- It just includes the user name, where we want to include userid and (where removing access) the related accountid.
Basically it doesn't work for us.
Ideally it would be possible to create an array variable as that would presumably be less subject to length constraints. If I try to concatenate all the changes together into a single string using something like the Oracle listagg function that has a maximum length of 4000 characters and it is not too hard to create a change request with sufficient changes to breach that limit.
It looks, though, as if the way that WF variables and in particular array variables are held in IGL has changed from IMG v6 (i.e. losing all that old XML) but how could we use these to include the line breaks (and ideally NOT display the comma separator)?
Sean Miller Edwin Mullie Frank Schubert Boris Lekumovich
Apologies for tagging you guys but this is really driving me crazy and I refuse to believe it is not solvable.
Fair comment, but I don't know if/how we could truncate it "nicely", i.e. between individual CRI details. Plus the folk handling the Remedy tickets don't usually have access back into IGL. Not sure the xmlagg option is worth the effort - looks inordinately complicated.
The alternative (which I think is acceptable) would be (somehow) to check the length of the generated array variable and if too big then bypass the ticket altogether and go to Plan B, which is an email requesting the ticket to be created manually. This is already plan B in case there are issues with the ticket interface (e.g. Remedy down, user not exist in Remedy) and the frequency of cases like this should be minimal. I've done some analysis on our CR history and almost all the extra large ones were users erroneously selecting ALL entitlements for an application and they should have been cancelled/rejected before they got to fulfilment anyway.