Execution FlowΒΆ


This iApp template uses a multi-stage execution flow to allow full deployment of services available on the BIG-IP platform. The number of stages used vary based on the specific features utilized during a particular deployment.

Each stage executes sequentially after the previous stage completes in the following order:

  1. Implementation layer TCL code
  2. Post depoly bundler iCall script to handle L4-7 policy deployment
  3. Post depoly final iCall script to handle deferred TMSH commands

Step 2 above is only executed if deployment of a L4-7 service policy is required. For more details on L4-7 policies see Resource Bundling & L4-7 Policies

Implementation Layer

The Implementation Layer consists of TCL code that executes sequentially and adheres to the underlying ordering required by the BIG-IP platform. The overall flow is as follows:

  1. Template startup (determine mode, debug level, input fix-up, etc)
  2. SSL/TLS Profile Creation
  3. Monitors
  4. Pools
  5. L7 Policy Creation (may be deferred to postdeploy_final)
  6. Virtual Servers
    1. Bundled iRules (see: Resource Bundling & L4-7 Policies)
    2. Profile Processing
    3. SNAT
    4. SSL/TLS Profiles
    5. Policies
    6. Additional Listeners
  7. Statistics Handlers
  8. Virtual Address Options
    1. Route Advertisement
    2. Advanced Options
  9. Post depoly bundler handler creation (only required for WAF/IAM policies)
  10. Post depoly final handler creation


The Post depoly bundler iCall script is scheduled for execution by the Implementation Layer as required. The primary purpose of this script is to create L4-7 policy elements (Resource Bundling & L4-7 Policies) and associate those policies with any required Virtual Servers. Execution can be tracked via the mechanisms detailed in Logging & Debugging or via specific iStat keys that are populated at each step of execution of the script. The iStat keys are tied to the Application Service Object (ASO) that is created by the iApp framework for each deployment. The iStat keys created are:

Key Name Possible States
deploy.postdeploy_bundler.asm.<po licy name>
deploy.postdeploy_bundler.apm.<po licy name>

The final action of the Post depoly bundler script is to create an iCall handler that executes the Post depoly final script.


The Post depoly final iCall script is scheduled for execution by either the Implementation Layer or the postdeploy_bundler script. The purpose of this script is to execute any final commands that have been deferred to this stage. Additionally this script populates iStat keys that should be used to determine success or failure of the deployment. The iStat keys created are:

Key Name Possible States
  • FINISHED_<epoch timestamp>

Determining Success/Failure of Deployment

To determine overall success of a deployment the upstream system should NOT rely on the state returned via the GUI or API on the initial creation of the deployment. Rather, the


iStat key should be queried for the

FINISHED_<epoch timestamp>

state. A reference implementation of this mechanism can be found in the depoly iapp script helper script. The mechanism implemented performs the following:

  1. Capture current start epoch time from deployment system

  2. Determine polling interval and max number of polls

  3. Loop until max number of polls

    1. Send REST POST to retrieve deploy.postdeploy_final iStat key

    2. Check if returned state starts with

      1. Check if timestamp returned in state is greater than start time
        1. Return success
    1. Sleep until next polling interval
  4. Return failure

The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.