F5 WSDL Auto-Import Service

Overview

The F5WsdlAutoImportService automates the discovery and onboarding of SOAP-based web services from F5 BIG-IP instances. It is designed to streamline the process of populating the API platform with services that are proxied through F5, reducing manual configuration effort.

The service operates by first probing an F5 instance for potential WSDL endpoints. For each successful probe, it fetches the WSDL, creates a corresponding WSDL artifact, and then uses the platform's zero-touch onboarding capability to generate a complete API service definition.

A key function of this service is its ability to associate historical traffic data with newly imported services. After creating a service, it scans traffic logs for requests matching the service's backend and retroactively assigns the new service ID to them. This enables immediate visibility into historical usage patterns. The service also rebuilds aggregated traffic statistics and generates learned examples and test datasets from this historical data.

This component is typically invoked by an administrative process or a scheduled job to periodically scan F5 instances and onboard new services.

How it Works

The auto-import process is orchestrated by the autoImportSuccessfulProbes method. The workflow involves discovery, validation, import, and post-processing of traffic data.

flowchart TD
    subgraph "F5WsdlAutoImportService"
        A[Start: autoImportSuccessfulProbes] --> B[Probe F5 for WSDL candidates];
        B --> C{Probe OK?};
        C -- No --> D[Abort and return failure];
        C -- Yes --> E[For each successful target];
        
        subgraph "Target Processing Loop"
            E --> F{WSDL URL exists?};
            F -- No --> G[Skip target];
            F -- Yes --> H[Find matching existing service];
            H --> I{Existing service found?};
            I -- Yes --> J{Can replace service?};
            J -- No --> K[Skip target];
            J -- Yes --> L[Delete existing shell service];
            I -- No --> L;
            L --> M[Fetch and import WSDL];
            M --> N[Onboard service via Autopilot];
            N --> O{Service created?};
            O -- Yes --> P[Relink historical traffic data];
            O -- No --> Q[Record result];
            P --> Q;
        end

        Q --> R[Compile summary];
        R --> S[End: Return results];
    end

1. Discovery

The process begins by calling the F5DiscoveryService.probeWsdlCandidates method. This method connects to a specified F5 instance and attempts to identify virtual servers that expose WSDL files. If this initial discovery phase fails, the entire import process is aborted.

2. Target Validation and Filtering

The service iterates through the list of potential service targets returned by the discovery probe. Each target is subject to several checks before an import is attempted:

• Probe Success: The individual probe for the target must have succeeded and returned a valid wsdlUrl.
• Existing Service Check: The service attempts to find an existing service that matches the target. A match is determined by:
  1. A combination of serviceKey and environment.
  2. The backend's base URL (endpoint_url in the s2r_backend_profile table). The search is strictly scoped to the current tenant to prevent cross-tenant conflicts.

3. Service Replacement Logic

If a matching service already exists, the system decides whether it can be replaced. An existing service can be automatically replaced only if it meets all the following criteria, identifying it as an auto-generated, non-active shell:

• Its environment is auto.
• Its status is not active.
• It has no active versions (active_version_no is null).

If an existing service is found but does not meet these criteria, the target is skipped to avoid overwriting a manually configured or active service. If the service can be replaced, it is permanently deleted (hardDelete) before the new service is imported.

4. WSDL Import and Service Onboarding

For a valid target, the service performs the following actions:

1. Fetch WSDL: It downloads the WSDL file from the wsdlUrl. The fetch has a 10-second connection timeout and a 20-second request timeout.
2. Create Artifact: The downloaded WSDL content is parsed, and a new WSDL artifact is created in the repository. This artifact is the source for the new service definition.
3. Onboard Service: The ZeroTouchOnboardingService.autopilot method is called with the new WSDL artifact. This generates a new service, including its operations and a default backend profile, based on the WSDL content.

5. Post-Import Data Processing

If a new service is successfully created, several data processing tasks are triggered to integrate the service with historical data.

Relinking Learned Traffic

The relinkLearnedTraffic method updates the s2r_traffic_log table. It finds all traffic log entries where the backend details (scheme, host, port, and URI) match the newly discovered service and service_id is null. It then updates these rows, setting the service_id, service_key, service_name, and environment to match the new service. This retroactively classifies previously unassigned traffic.

Rebuilding Aggregates and Examples

After relinking traffic, the service rebuilds derived data:

1. Hourly Traffic (rebuildTrafficHourly): All existing records for the service in s2r_f5_traffic_hourly are deleted. New aggregated hourly traffic counts are then inserted based on the now-complete data in s2r_traffic_log.
2. Learned Examples (rebuildLearnedExamples): All existing records for the service in s2r_learned_example are deleted. The service then queries s2r_traffic_log to find unique request payloads for the service, aggregates them, and inserts them as new learned examples.

Syncing Test Datasets

Finally, if the new service has a default backend profile, the syncTopExamplesIntoDatasets method is called. This method takes up to 20 of the most frequently seen learned examples and creates or updates corresponding entries in the s2r_service_test_dataset table. These datasets are named F5 Learned Example N (where N is 1 to 20) and can be used for testing the API. Any stale learned example datasets beyond the top 20 for the service are removed.

API Reference

The service exposes a single method for initiating the auto-import process.

autoImportSuccessfulProbes

This method orchestrates the entire discovery and import workflow.

Parameters

Return Value

The method returns a Map<String, Object> containing a detailed report of the operation. The source does not provide a concrete JSON example of the response. The structure is as follows:

• status (String): The overall status of the operation. Either ok or failed.
• checkedAt (String): The ISO 8601 timestamp when the operation was completed.
• probe (Map): The raw result map returned by the F5DiscoveryService.probeWsdlCandidates method.
• summary (Map): A summary of the import results.
  • requestedCount (int): The total number of targets processed.
  • successCount (int): The number of targets successfully imported.
  • skippedCount (int): The number of targets skipped.
  • failedCount (int): The number of targets that failed during import.
• results (List<Map>): A list containing a detailed result for each processed target.
  • success (boolean): true if the import was successful, otherwise false.
  • status (String): The outcome for this target: imported, skipped, or failed.
  • reason (String): An explanation for a skipped or failed status.
  • target (Map): The original target map from the F5 discovery probe.
  • artifactId (UUID): The ID of the created WSDL artifact (on success).
  • serviceId (UUID): The ID of the created service (on success).
  • versionId (UUID): The ID of the created service version (on success).
  • replacedAutoShell (boolean): true if a pre-existing auto-generated service shell was replaced.
  • deletedShell (Map): Details of the shell service that was deleted and replaced (if applicable).
  • existingService (Map): Details of a pre-existing service that was found but not replaced, causing the target to be skipped.

Troubleshooting

The import process for a target can fail or be skipped for several reasons. The status and reason fields in the response for each target provide details.

See Also

• F5 Discovery Service: The component responsible for probing F5 BIG-IP instances to find WSDL candidates.
• Zero-Touch Onboarding Service: The component that creates a complete service definition from a WSDL artifact.

All SOAP-to-REST docs