Goals

The high level goals for this project are as follows:

• Enable utilization of the full F5 L4-7 feature set while masking complexity from NorthBound systems
• Cover the most common deployment use cases as standard, community supported, features
• Provide simple extension mechanisms for customization that may be required in your environment
• Minimize (over time) changes to the NorthBound API Data Model
• Normalize F5 specific configuration as much as possible between all integrations
• Rapidly deliver new features and functionality
• Support a broad range of F5 BIG-IP software releases

iApp Basics & Constraints

Note

For full documentation on iApp’s please refer to the F5 DevCentral iApp Wiki This documentation is limited to explaining how we utilize the iApp infrastructure with this particular project.

Basic Terms

Term	Definition
iApp template	A file (.tmpl extension) that contains the tmsh importable definition of an iApp. The template contains the implementation and presentation layers along with other settings
Presentatio n layer	The APL definition of the user interface and API data model for the iApp template
Implementat ion layer	The TCL based tmsh script that actually processes input defined in the presentation layer and deploys a configuration on the BIG-IP device
[North/Sout h]bound	The direction of API calls in an implementation. Northbound generally implies integration with another system or product through a standardized API (REST, SOAP, etc). Southbound generally implies vendor specific integration through open or non-standards based APIs
BIG-IP	The data plane element that executes the implementation layer code of an iApp template and deploys a config to process network traffic
iWorkflow	The optional control plane element that interacts with and manipulates the presentation layer of an iApp

Presentation Layer Contraints

To provide the broadest compatibility with third-party systems we implement a very simple presentation layer. Advanced TCL-based programmatic logic in the presentation layer is not implemented by this iApp (even though APL supports this). The reasoning behind this is that there is no reliable, standard way to execute logical arguments in third party systems. Some simple use cases are implemented (e.g. auto-population of a dropdown), however, these are only useful when the iApp Presentation Layer is rendered via the BIG-IP GUI. As a result all functionality implemented is required to function correctly without this programmatic logic.

Implementation Layer Constraints

Within the implementation layer we have a lot more flexibility in how features are implemented. Generally, anything is possible, however we take care to implement features in a manner that can work with all possible integrations.

All deployments are fully Partition and Route-Domain aware to enable full multi-tenancy. When running in Standalone mode users may choose to simply use the Common partition and route-domain 0 to achieve a non-multi-tenant config, however, the implementation of all features should enable multi-tenancy by default.

Furthermore, all implementation layer code must be compatible with all modes unless specifically enabled only for a particular mode and documented clearly. Introduction of additional presentation layer fields for mode-specific options should be avoided to maintain the simplest possible user and API interface.