Automic Workload Automation

 View Only
Expand all | Collapse all

URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

  • 1.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 06, 2018 08:53 PM
    I ran an API call that modified about 691 objects and removed an old unused promptset. It turns out that when I removed the promptset it erased all the values of the other promptset that was part of that job object (guessing this is another bug with the api). I would like to get the old values of the promptset back into the job, but if I can't do that I need to revert all these objects to an older version.

    Any ideas on how to first FIND all the objects that were modified? I've tried the OPUD table, but it doesn't have the old promptsets associated with the jobs.  I've tried the OH table, but too many jobs get returned that were modified around the same time via the api user. Is there a query that will return me the objects that HAD that missing promptset that I can then go and restore? Or even better some way to refill those values into the promptset?


  • 2.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 06, 2018 10:25 PM
    Or can I restore by modifying the OH table?


  • 3.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 07, 2018 05:02 AM

    **** NO!

    Query OH table with DeleteFlag limitation. Then you get the versioned objects. In case you have versioning active. Then you can use the API to restore the latest version of the object.



  • 4.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 14, 2018 03:19 PM
    No API for restoring. At least I couldn't find it in the code.


  • 5.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects



  • 6.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 15, 2018 03:01 PM
    This restores items from the Recycle Bin.
    I found the way to be able to do it is 
    https://docs.automic.com/documentation/webhelp/english/AWA/11.2/AE/11.2/API/com/uc4/communication/requests/RestoreObjectVersion.html
    Which would require using this other function to get the XML text
    https://docs.automic.com/documentation/webhelp/english/AWA/11.2/AE/11.2/API/com/uc4/api/objects/DocuContainer.html

    I'd have to OpenObject, get the XML and run that through a RestoreObjectVersion. Rather than just Click Restore button on the documentation tab, with the version I'd want. It's not a big deal, but it's not simple.


  • 7.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 15, 2018 04:29 PM
    Jeah I see the point. You got to be very careful with promptsets when it comes to values. You should be able to find the data in the database however. So you might also extract data from the database and set it again using the API. Anyway - it's still not simple.


  • 8.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 17, 2018 04:57 PM
    Yeah, because it was urgent, I went through an manually fixed over 600 jobs to restore them. The Java API is really bad at handling promptsets. Right now I'm thinking about adding a Process Tab to about 380 workflows, and I'm thinking it would be less risky to just add those rows to the OT table rather than risk using the api to do it. 


  • 9.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 18, 2018 11:43 AM
    Automic rule #1: thou shall not directly modify thei database.


  • 10.  URGENT: need to restore an old version of an object, but need QUERY to find the changed objects

    Posted Mar 19, 2018 05:14 AM
    Automic Rule #2:

    sometimes, you need to modify the database directly, or SQL is the only reasonable way to get something done.

    In that case, make up your suggested SQL statement and send it to Automic support to have it approved, along with the reasoning why this is without a reasonable alternative.

    If they agree, they will pass your SQL to a developer who will look at it and consider side effects. He will send it back via support. When it comes back and has been modified, one is well advised to check it again, because they might have modified it in a faulty, incompatible with your DB dialect, or worst case, even dangerous way. Over some iterations, consensus can then be reached on a safe SQL statement, and only a few days later, one can execute an automic-approved SQL statement while enjoying full support (hopefully).

    At least that's how it worked for me when we insisted that we'd rather run an SQL statement than open and modify about 6000 SAP jobs each, one after another.

    Hth,
    Carsten