DOCSEARCHbyAlgolia
Submit Docs

Frank!Framework Documentation

website·Indexed 32 days ago

https://docs.frankframework.org

Documentation for Frank!Framework, a Java-based integration framework. Covers XML configuration, pipeline flow control, database access, Docker deployment, and operational tools like Frank!Flow graphical editor, Larva and Ladybug testing, and Quartz scheduling.

Tokens
34.2K
Snippets
167
Records
254
Agent score
51%

What's inside Frank!Framework

  1. Overview of Frank!Flow graphical editor

    Frank!Flow is a browser-based graphical editor for Frank configurations. It provides a drag-and-drop interface to build and edit adapter pipelines visually as an alternative to writing XML directly. It can render existing XML configurations as diagrams and generate valid configuration XML from visual representations.

  2. Overview of Larva adapter testing

    Larva is used to test Frank!Framework adapters in isolation (unit tests). It avoids the resource-intensive setup of full integration environments by replacing external system interfaces with direct Java call stubs. Tests are defined using a properties-based scripting language where scenarios send input messages to an adapter and verify the output against expected values.

  3. Overview of Ladybug Report Capture and Replay

    Ladybug captures adapter executions as reports containing checkpoints (input/output at each processing step). These reports can be used for regression testing by capturing them as test reports and replaying them. Access Ladybug via Testing → Ladybug in the Frank!Console.

    • Debug Tab: Displays live reports of adapter executions and provides tree views of report contents.
    • Test Tab: Manages captured test reports, including running, organizing, and comparing results.

  4. Overview of Frank!Framework Credential Factories

    Credential factories manage secrets (usernames and passwords) by storing them outside of Frank configurations and log files. Credentials are referenced in the system by alias names. Available factories include:
    FactoryClassAdditional Properties
    Property Fileorg.frankframework.credentialprovider.PropertyFileCredentialFactorycredentialFactory.map.properties
    File Systemorg.frankframework.credentialprovider.FileSystemCredentialFactorycredentialFactory.filesystem.root, credentialFactory.filesystem.usernamefile, credentialFactory.filesystem.passwordfile
    Ansible Vaultorg.frankframework.credentialprovider.AnsibleVaultCredentialFactorycredentialFactory.ansibleVault.vaultFile, credentialFactory.keyFile

  5. Understand Frank!Framework error response behavior

    Error message formatters determine the structure and content of the response sent back to a caller when a pipeline finishes with a state other than SUCCESS or when an unhandled exception occurs. By default, the framework wraps error information (error message, adapter name, and message ID) in an XML envelope, with the exact format depending on the listener type that received the request.

  6. Understand message flow and default input behavior in pipelines

    In a Frank!Framework pipeline, a message flows sequentially from one pipe to the next. By default, the first pipe receives the pipeline's initial input message, and every subsequent pipe receives the output message of the previous pipe as its input. The framework automatically stores the initial pipeline input message in a session key named originalMessage.

  7. Understand Frank!Framework core architectural concepts

    Frank!Framework is a low-code integration framework that uses XML configuration to build message-based adapters. The core components are:

    • Adapter: A self-contained integration flow consisting of a receiver and a pipeline.
    • Receiver: The entry point that listens for incoming messages (e.g., HTTP, JMS, file polling, or scheduling).
    • Pipeline: A sequence of pipes that process a message step-by-step.
    • Pipe: An individual processing unit, such as an XSLT transformation, database query, API call, or validation.
    • Sender: The component that delivers the processed message to an external system or resource.

  8. Suppress framework warnings

    Use these properties to silence specific warnings:

    • warnings.suppress.defaultvalue: Suppresses warnings about redundant default value assignments. Default: false.
    • warnings.suppress.sqlInjections.ManageDatabase: Suppresses SQL injection warnings specifically for the ManageDatabase adapter. Default: false.
    • warnings.suppress.sqlInjections.<adapter>: Suppresses SQL injection warnings for a specific adapter that intentionally uses dynamic SQL.

  9. Understand Frank!Framework monitoring core concepts

    The monitoring system uses the following components to manage operational alerts:

    • Monitor: A named state that is either raised or not raised, scoped to a single configuration.
    • Trigger: Changes the monitor state. There are two types: Alarm (raises the monitor) and Clearing (clears the monitor).
    • Event: A framework occurrence (e.g., Pipe Exception, Receiver Shutdown) that fires a trigger.
    • Threshold: The number of events required before a trigger fires.
    • Period: The time window (in seconds) within which the threshold must be reached.
    • Destination: The action performed when a monitor is raised.
    • Tags: Visual classifications including TECHNICAL, FUNCTIONAL, HEARTBEAT, and CLEARING.

  10. Capture and run test reports in Ladybug

    To capture a test report:

    1. In the Debug tab, select a report row.
    2. Select the uppermost "Pipeline" node in the tree view.
    3. Choose a stub strategy (e.g., "Never" or "Always").
    4. Press Copy to capture the report to the Test tab.

    To run captured tests:

    1. Go to the Test tab and press Refresh.
    2. Select the desired tests and press Run.
    3. Press Refresh to view results (Green = Pass, Red = Fail).

    Use the Compare feature to investigate failures by viewing expected vs. actual results side-by-side with differences highlighted in red.

  11. Manage failed messages using the Error Store

    The Error Store uses <JdbcErrorStorage> to store messages that failed processing, preventing message loss in 'Fire and Forget' patterns. When a message fails, the transaction rolls back and the message is moved to the error store.

    To manage failed messages in the Frank!Console:

    1. Navigate to Adapter Status.
    2. Click the red error store icon (with count badge) next to the adapter's receiver.
    3. Review the Message ID, Correlation ID, timestamp, and error reason.
    4. Select messages and click Resend to reprocess them or Delete to remove them.
    5. Use Resend all or Delete all for bulk operations.