Looping Web Service Calls in AppWorx

… or UC4 Applications Manager or Automic Workload Automation Suite or whatever it is called now

The unjoys of using AppWorx with the Integrations API of the Workday product.

This does not cover how to setup a Web Service call in AppWorx.  My general advice there is: Don’t.  The AppWorx UI can get wretched quickly with SOAP objects and the setup here will likely take much more time than coding.  Script your web services instead in something like Python or Ruby where you can exercise much more control over them — especially if you have a sequence of calls you need to make and respond to.  We did not do it this way, however, so I got stuck with trying to improve what we were stuck with.

We have a strange hybrid system where AppWorx initiates the first web service to start a remote operation.  Then, an OS script takes over to tell AppWorx to initiate the second web service which checks the status of the first operation.  This script also monitors the status file for completion and tells AppWorx to redo the call if needed.  To make matters even worse, the developers responsible for creating and maintaining these web service jobs don’t have access to this OS script… the DBAs do.  Thus, repairs require coordination with a group that usually has better things to do.  And, well, if it ran flawlessly, fine… but it don’t (yeah, it causes bad grammar too).

I was convinced this OS script was not needed so I set about finding an all-AppWorx solution.  They said it couldn’t be done.  Yeah, well, whatever.  How many times have we all heard that one before?  Here’s how to set the conditions on the second web service job so that it loops itself until it finds a result other than “Processing”:

Screenshot of GET_INTEGRATION_EVENTS Conditions

Code Comments by line:

  1. Sets initial delay.  HH:mm:ss
  2. Sets max duration of component (how long will we let it loop).  NOTE: this uses “time since request” which means if the job gets stuck in the backlog for some reason, then that time spent in the backlog will count against this time and may cause this to abort sooner than expected.  Also, remember to add in the initial delay if wanted (such as: if initial delay is 15 minutes then perhaps set this to 1 hour and 15 minutes).
  3. Checks for the abort executed by line 2 (the max duration).  Because the line-2 abort executed in a BEFORE condition, the AFTER conditions will still process so we must check for the abort here ahead of the rest of the AFTER stuff.  (Performed ONCE because it only needs to be true once — conditions performed ONCE will still be checked on each loop until true — not exactly clear English on UC4’s part.  If it needs to be true more than once, then select CONTINUOUS.)
  4. Clear the subvar before first use.  (Yes, it also sets the value to NO_VAR_FILE but the main point here is to set something before first use since AppWorx tends to store these perpetually.)
  5. Grab the web service variable out of it’s file, $AW_HOME/web/classes/webserviceExecAgentVariableDir/{chain_id}_current_status, and load it into our subvar.
  6. If the status is “Processing” then set the RESTART ON ABORT flag to Y.
  7. If the status is “Processing” then abort with a message of “ok_restart” or “restarting” or whatever is chosen as standard.  Lines 6 and 7 together perform the polling loops.
  8. If the status is “Completed” then finish with a message of “Completed”.
  9. (Optional)  If the status is “Completed with Warnings” then finish with a message of “WithWarnings”.  Might instead set to abort if desired.
  10. (Optional)  If the status is “Completed With Warnings” then abort with a message of “WebServError”.  Might instead set to finish successfully if desired.  NOTE: Workday does not seem to be consistent with caps such as “with” and “With.”
  11. (Optional)  If the status is “NO_VAR_FILE” then the attempt to load the variable from the file failed for some reason (line 5) and abort with a message of “NO_VAR_FILE”.
  12. Else, abort.  Aborts with the usual ABORTD message — setting a custom message here could be useful but probably not worth the discussion.


  • See the notes in the comments for line 2 for the max duration caveat.
  • Setting a specific delay time between loops is not accomplished in this logic.  By default, AppWorx rechecks its conditions every 30 seconds which means this loops every 30 seconds (plus one or two extra seconds maybe).  It would seem logical that setting a BEFORE/CONTINUOUS/ALWAYS TRUE/DELAY TASK condition would accomplish this but such a condition will delay itself indefinitely because it is “always true” and DELAY TASK always reruns itself before any other condition that you might otherwise use to turn the continuous delay switch off.  What might be needed is something more like a SLEEP action, which does not exist.  Yes, I tried creative branching with variables and GOTO but got nowhere that proved continuously repeatable.  Have at it if you will.  Perhaps we will get a new feature for this someday — or they change the behavior of DELAY TASK.

That said, if needed, we could possibly create a pause the hard way, if worth the effort.  We could create a subvar that queries the database and builds a HH:mm:ss string X minutes out and use it in a CURRENT TIME/WAIT UNTIL MET or ALWAYS TRUE/RESCHEDULE TASK condition (or something similar).  Midnight could cause trouble depending on how things are built (for example, this is a problem: 23:59 > 00:01).  [I thought about a similar solution for the line-2 caveat but, again, midnight is a bigger problem there.  There are no datetime features that I see.]

Calling a host command such as the “sleep” command was tested but AppWorx does not wait for host commands to finish before continuing processing conditions (logical).  Thus, to make a host command work, it would have to do something like write a message to a file and then follow it with a CHECK FILE/WAIT UNTIL MET condition.  That could create a file mess.


This was just a quick post in case anyone happens to find it useful (and, hopefully, nobody will because you all headed my warning to not use the Web Service feature of AppWorx).  Take it, expand it, make it your own.  I’m probably not interested in improving the writing or in answering any questions on it.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s