Hi all
I currently try to create a resource element in vRO, and I check before if already exists, if yes I delete it.
But even if the resource element is well deleted, the function Server.createResourceElement() returns that it already exists.
is it a bug ? does I need to perform a refresh or anything else ?
Thanks for your help
Below the code to reproduce the error :
var resourceCategoryPath = "Test"
// Build mime file
var fileName = "test.txt"
var fileContent = "test"
var mimeFile = new MimeAttachment()
mimeFile.name = fileName
mimeFile.content = fileContent
// Check if exists
var resourceElement = System.getModule("com.vmware.o11n.plugin.dynamictypes.configuration").getResourceElementByName(resourceCategoryPath + "/" + fileName)
// If exists delete it
if (resourceElement)
{
Server.removeResourceElement(resourceElement)
System.log("resource element deleted")
}
// then create resource element again (with same name)
var resourceElement = Server.createResourceElement(resourceCategoryPath, fileName, mimeFile, "text/plain")
And the logs:
[2019-03-07 17:09:25.328] [I] resource element deleted
[2019-03-07 17:09:25.332] [E] An element with the same name already exists in the category.
[2019-03-07 17:09:25.339] [E] Workflow execution stack:
***
item: 'test/item1', state: 'failed', business state: 'null', exception: 'An element with the same name already exists in the category.'
workflow: 'test' (9947d019-bef4-4fd6-80e9-9c8041fef297)
| 'no inputs'
| 'no outputs'
| 'no attributes'
*** End of execution stack.
iiliev - Yes, you're correct. I've tried my own suggestion there with 7.5 and it blows up no matter what wait time I put in. I've found that using the a workflow to remove the resource will work fine + the client will even remove the resource from the UI view but even if I use the client action to re-upload the resource I get the already exists error. If I use the global client UI refresh action that seems to clear the cached reference (very slow to complete too...) and then I re-create/re-upload with no problems.
As I said before, I think I found the delay approach worked before but it may have been in an older version as it was a while back.
As a last suggestion to the OP, looking at your use case, all you're really doing is replacing the content of the resource, then you can get to the same end-game by just updating the resource content with the content of the file?
Like this
This way you're avoiding this bug but getting the resource updated as you need
HTH
Hi,
I will try to reproduce the error in my lab. Could you tell me the version / build number of vRO you are using?
Hi Ilian
I tried with vRO 7.2 and vRO 7.5 with same results.
Thanks for your help
I'm pretty sure I had this before and found that putting a delay between the delete and re-create gives the DB transaction for the delete a chance to get all the way through the database.
You can either use System.sleep (which can be bad for long delays as it retains all Thread & Monitor locks at the Java level) or use this util action which is based on the Java Object.wait() (releases locks etc - handy when you want to do a comparatively long wait, say > 10 seconds)
If you put say a 5 second wait between the delete and re-create is it any better?
OK, I reproduced it in my environment.
eoinbyrne - I don't think adding a delay will help; seems more like a caching issue (resource category continuing to keep reference to the deleted element)
iiliev - Yes, you're correct. I've tried my own suggestion there with 7.5 and it blows up no matter what wait time I put in. I've found that using the a workflow to remove the resource will work fine + the client will even remove the resource from the UI view but even if I use the client action to re-upload the resource I get the already exists error. If I use the global client UI refresh action that seems to clear the cached reference (very slow to complete too...) and then I re-create/re-upload with no problems.
As I said before, I think I found the delay approach worked before but it may have been in an older version as it was a while back.
As a last suggestion to the OP, looking at your use case, all you're really doing is replacing the content of the resource, then you can get to the same end-game by just updating the resource content with the content of the file?
Like this
This way you're avoiding this bug but getting the resource updated as you need
HTH
Hi eoinbyrne
I think your suggestion is the best answer (and workaround).
I did it and it's solved my problem.
Thanks for your help.