2 Replies Latest reply on Jun 14, 2019 4:42 PM by Peter Lundqvist

    How to ensure data is committed in workflow

    Peter Lundqvist
      Share This:

      I have a small application that uses APL.ARDBC.RESTFULARDBCPLUGIN (not important to the question) to communicate with an external system.

      This works fine if I use the forms manually. But when I try to use the forms in a workflow it fails because the token from the login is not comited yet.


      I have a filter guide that looks a bit like this:

      FOO:INT:Push data:Guide

           FOO:INT:Push data:G:Login`!

                Set Fields    server | FOO:Config | $Status$ < "Rejected"

                Set Fields    server | RemoteSystem:Authenticate ('ROOT:User'=$remoteuser$ AND 'ROOT:Password'=$pwd$)

                Push Fields   server | APL:RestfulVendorForms:Table | 'Table'="RemoteSystem:API Call 01"

                Push Fields   server | FOO:Config | $Status$ < "Rejected"

           FOO:INT:Push data:G:API Call 01

                Set Fields    server | RemoteSyste:API Call 01 | ('ROOT:SetValue'=$value$)

                Set Fields    CURRENT TRANSACTION


      FOO:INT:Push data:G:Login`! reads the username and password from the configuration form (FOO:Config), authenticates against the remote system and gets back a token for further API calls. It then uppdates the headers in the APL:RestfulVendorForms:Table table with that token. It also saves a timestamp for the authentication token in the FOO:Config form.


      FOO:INT:PUSH data:G:API Call 01 then performs the API call to the remote system. This, however, fails because the first Push Fields action in FOO:INT:Push data:G:Login`! is not completed yet. In fact, it completes AFTER the second filter has completed. I am now reading the filter phase documentation and scratching my head.

      How do I ensure that the authentication token is written to APL:RestfulVendorForms:Table before the second filter starts running?

        • 1. Re: How to ensure data is committed in workflow
          LJ LongWing


          The direct answer to your question is 'Application-Release-Pending'....or whatever it's exact name...that will tell it to release all of the stuff that's currently pending db connect....


          But...the better answer to your question is this.


          Instead of storing the token in the Table record, replace the header value with a field variable, then pass the current token into the Vendor form as a part of the field mappings, the plugin will automatically replace the value in the header with the field value you pass in....


          So, in effect the process will be thes


          Check to see if the current token is good, if yes, get it and pass it into the vendor form

          if token is expired, run process to get new token and update the config form with the new token, then pass it to the vendor form


          that way you don't need to update the table record with the token, but you are still managing it properly.

          3 of 3 people found this helpful
          • 2. Re: How to ensure data is committed in workflow
            Peter Lundqvist

            That is a much cleaner solution and it worked like a charm!

            Many, many thanks!