uCMDB Expert days - Question #3
For some CIs and for some of their attributes, it seems we can find some carriage returns into the string.
It's when exporting to .CSV format, transforming the 1st column from "Text to Column" and each time there's a carriage return found, the data of the attribute are stored in column A.
see attached document
Is there a solution on how to eliminate the carriage return within the attribute?
This might indeed happen.
I think the best solution here would be to transform string attribute to remove any carriage return from it prior to export to CSV.
But this is an Enhancement Request, as it requires some code change on UCMDB server side.
Hope this helps
Thank you Pierre for your answer.
I know how to fix this issue using Java extraction with a replace function but I have no idea how to implement an enrichment rule for that.
Any help would be appreciated
Hi again Bruno,
indeed, this would simply be using java String's replace() method, but there is no way to use this in a enrichment rule.
That's why I mentioned the ER, as it is by far the simplest way, from a user perspective.
Now, if you like to code:
1) with java, you can use the UCMDB java api, retrieve nodes you'd want to remove the carriage return from their attribute value, and then send them back in UCMDB for update, usina java api again.
2) using Jython, you could create a custom job, that would fetch those CI from UCMDB, check if they need this attribute to be updated, and send them back, as would an ordinary job do.
Now, building your TQL to fetch those CIs, I do not think you can use a regular expression to check the presence of "\n" or "\r\n". You'd need therefore to get all of possible CIs to edit, parse them one by one, replace attribute value when needed, and send back only updated ones.
From the server to your client code, it would represent possibly a large amount of data to transfer, most certainly a smaller amount of CIs to be sent back to server for update. You can recreate them using their CMDB_ID, only setting then the updated attribute. This would limit the impact on the server while re-inserting them for update, but still, there will be some overhead.
I do not know the usual load on your UCMDB server, so I cannot say if that would be a possible problem for you or not to run such codes.
Hope this helps.