Automic Workload Automation

 View Only
  • 1.  Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 05, 2019 06:11 AM
    I recently discovered that data written to a static VARA object using :PUT_VAR is not immediately accessible using GET_VAR. If I insert a :WAIT 1 statement between the :PUT_VAR and the GET_VAR, it works. Is this a bug, or is the Automation Engine working as designed? Is there a better work-around than deliberately slowing down the script?

    #caautomicworkloadautomation #automationenginescript #:put_var #static_vara​​​​​​​​​​


  • 2.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 05, 2019 01:16 PM
    I just tested this behavior in V11.2.4, and could not replicate it.   As I plan for our upgrade to V12, it concerns me and I will add it to my test plan.


  • 3.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 05, 2019 01:16 PM
    Edited by Pete Wirfs Jun 05, 2019 01:23 PM
    (wiping duplicate post.  Didn't know there was a delay for replies to get posted.  And there doesn't seem to be a delete option?)


  • 4.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 06, 2019 03:51 AM
    Hi @Michael A. Lowry,
    I've tested your behavior in 12.2.2.hf4 and it works as expected. (without wait)​

    ------------------------------
    Thx & rgds
    Christian
    ------------------------------



  • 5.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 06, 2019 09:52 AM
    Edited by Michael A. Lowry Jun 06, 2019 10:19 AM
    This might be relevant: The GET_VAR statement does not access the static VARA directly. Instead, it accesses an EXEC VARA that runs an SQL job to look for rows in the static VARA matching specific criteria. The SQL looks like this:
    WITH VaraContent AS (
    SELECT DBMS_LOB.SUBSTR(OVW_VValue, 4000, 1) AS Key,
    DBMS_LOB.SUBSTR(OVW_Value1, 4000, 1) AS Value1,
    DBMS_LOB.SUBSTR(OVW_Value2, 4000, 1) AS Value2,
    DBMS_LOB.SUBSTR(OVW_Value3, 4000, 1) AS Value3,
    DBMS_LOB.SUBSTR(OVW_Value4, 4000, 1) AS Value4,
    DBMS_LOB.SUBSTR(OVW_Value5, 4000, 1) AS Value5
    FROM &OH#, &OVW#
    WHERE OH_IDnr = OVW_OH_Idnr
    AND OH_OType = 'VARA'
    AND OH_Client = &UC4_Client_ID#
    AND OH_DeleteFlag = 0
    AND OH_Name = '&Migration_Data_VARA#'
    )
    select Key,Value1,Value2,Value3,Value4,Value5 from VaraContent
    &SQL_Predicate#

    I can imagine that the AE returns the correct values immediately even if the values have not yet been committed to the DB, but only if the following two criteria are met:
    • the :PUT_VAR and GET_VAR are run by the same WP (e.g., in the same SCRI); and
    • the :PUT_VAR and GET_VAR directly access exactly the same VARA object.
    In my case, an ordinary GET_VAR against the static VARA won't let me return just the data I want, so I had to go via the EXEC VARA & SQL job.


  • 6.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 06, 2019 04:38 PM
    I have experienced this behaviour already in version 9 in very tight timing situations with an Oracle database. Afaik the AE implements some time slicing when executing scripts, so the execution is not guaranteed to be done in one WP resp. one database session/transaction.

    This is what the docu says:

    https://docs.automic.com/documentation/webhelp/english/AWA/12.2/DOCU/12.2/AWA%20Guides/help.htm#Script/Writing/Script_Processing_Order.htm

    The Automation Engine processes scripts line by line. The results of executed script elements (such as the value of a variable that has been set) are regularly written to the AE database. This process is referred to as a commit. Other scripts can only access these new or modified values after the values have been committed.

    When scripts run for longer times, the Automation Engine automatically makes a commit every 5 seconds. In addition, some script elements that require processes to complete also result in commits.

    Examples

    Some script elements start or stop tasks, and wait for the RunID of the task to be returned, therefore resulting in a commit. The following functions are examples of such script elements:

    ACTIVATE_UC_OBJECT
    CANCEL_UC_OBJECT
    RESTART_UC_OBJECT
    Some script statements require user interaction. The system waits for the user to react, so script statements such as the following also result in a commit:

    :BEGINREAD... :ENDREAD
    :READ
    The :WAIT script statement instructs the system to wait for a specific length of time, and also results in a commit.

    Tip: Use :WAIT to enforce a commit.


  • 7.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible
    Best Answer

    Posted Jun 07, 2019 04:21 AM
    Edited by Michael A. Lowry Jun 07, 2019 05:46 AM
    @Siegfried Gyuricsko wrote:
    I have experienced this behaviour already in version 9 in very tight timing situations with an Oracle database. Afaik the AE implements some time slicing when executing scripts, so the execution is not guaranteed to be done in one WP resp. one database session/transaction.

    This is what the docu says:

    The Automation Engine processes scripts line by line. The results of executed script elements (such as the value of a variable that has been set) are regularly written to the AE database. This process is referred to as a commit. Other scripts can only access these new or modified values after the values have been committed.

    When scripts run for longer times, the Automation Engine automatically makes a commit every 5 seconds. In addition, some script elements that require processes to complete also result in commits.
    ...
    The :WAIT script statement instructs the system to wait for a specific length of time, and also results in a commit.

    Tip: Use :WAIT to enforce a commit.
    Siegfried Gyuricsko,  06-06-2019 03:50 PM
    I discovered that :WAIT 0 is accepted as a valid command, and also forces a commit to the DB. I changed the at :WAIT 1 statement at the beginning of the pre-process of the SQL job to just :WAIT 0. It works fine, and is obviously somewhat faster.


  • 8.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 07, 2019 03:33 AM
    Hi Michael,

    allow me just two small comments on the SQL-code:
    • there is no need for a dbms_lob.substr on OVW_VValue because it's not a LOB, it's actualle a varchar2(200), the reason being that it's indexed.
    • when you specify the OH_Client and the full OH_Name (without wildcards), like in your query, there is no need to specify OH_Otype or OH_Deleteflag, because the unique key UK_OH_Name on OH makes sure that the combination of Client and Name must be unique.

    Cheers,

    Philipp



    ------------------------------
    Philipp Elmer
    ------------------------------



  • 9.  RE: Data written to static VARA object with :PUT_VAR not immediately accessible

    Posted Jun 07, 2019 04:20 AM

    @Philipp Elmer wrote:
    allow me just two small comments on the SQL-code:

    there is no need for a dbms_lob.substr on OVW_VValue because it's not a LOB, it's actualle a varchar2(200), the reason being that it's indexed.
    when you specify the OH_Client and the full OH_Name (without wildcards), like in your query, there is no need to specify OH_Otype or OH_Deleteflag, because the unique key UK_OH_Name on OH makes sure that the combination of Client and Name must be unique.
    Philipp Elmer,  06-07-2019 03:30 AM
    Thanks. I have updated the query.

    WITH VaraContent AS (
    SELECT OVW_VValue AS Key,
    DBMS_LOB.SUBSTR(OVW_Value1, 4000, 1) AS Value1,
    DBMS_LOB.SUBSTR(OVW_Value2, 4000, 1) AS Value2,
    DBMS_LOB.SUBSTR(OVW_Value3, 4000, 1) AS Value3,
    DBMS_LOB.SUBSTR(OVW_Value4, 4000, 1) AS Value4,
    DBMS_LOB.SUBSTR(OVW_Value5, 4000, 1) AS Value5
    FROM &OH#, &OVW#
    WHERE OH_IDnr = OVW_OH_Idnr
    AND OH_Client = &UC4_Client_ID#
    AND OH_Name = '&Migration_Data_VARA#'
    )
    select Key,Value1,Value2,Value3,Value4,Value5 from VaraContent
    &SQL_Predicate#