RULE EXECUTION WORKFLOW:

PREREQUISITE STEPS: 0. MANDATORY: Check rule status to ensure rule is fully developed before execution

1. User chooses to execute rule after creation

2. Extract unique appTags from selected tasks (excluding 'nocredapp')

3. APPLICATION CONFIGURATION (OPTIONAL - only for tasks requiring credentials): For tasks that need application credentials:

   • Fetch available applications via get_applications_for_tag().

   • Present them to the user for manual selection.

   • User decides to: a. Use an existing application, or b. Run with new credentials (not persisted or saved as an application).

   • Proceed after user confirmation.

   Note: Rules with only 'nocredapp' tasks can be executed without any application configuration.

APPLICATION-TASK MATCHING LOGIC (when applications are needed):

• Applications are matched to tasks via 'appTags' labels

• Tasks with 'nocredapp' appType do not require application configuration

• SHARED APPLICATION SUPPORT: A single application CAN be used for multiple tasks if the user confirms they want to share the same credentials

• When multiple tasks share the same appType AND require DIFFERENT applications, unique identifier key-value pairs MUST be added to distinguish them

MATCHING SCENARIOS:

1. One application per task: Each task has unique appType → straightforward matching

2. Shared application: Multiple tasks share same appType AND same application

   • User confirms: "Use same application for all [appType] tasks? (yes/no)"

   • If yes: Single application covers all matching tasks

   • Application appTags should match the common appType

3. Multiple applications for same appType: Different credentials needed for different tasks

   • Add unique identifier key (e.g., "purpose", "sourceSystem") to distinguish

   • Each application's appTags must include the unique identifier matching its target task

APPLICATION CONFIGURATION FORMAT (when needed): For existing application (can be shared across multiple tasks): json [ { "applicationType": "[application_class_name from fetch_applications(appType)]", "applicationId": "[Actual application ID chosen by user]", "appTags": "[Complete object from rule spec.tasks[].appTags]" } ]

For new credentials: json [ { "applicationType": "[application_class_name from fetch_applications(appType)]", "appURL": "[Application URL from user (optional - can be empty string)]", "credentialType": "[User chosen credential type]", "credentialValues": { "[User provided credentials]" }, "appTags": "[Complete object from rule spec.tasks[].appTags]" } ]

WORKFLOW FOR MULTIPLE TASKS WITH SAME APPTYPE:

1. Detect tasks sharing same appType (excluding 'nocredapp')

2. Ask user: "Tasks [task1, task2] both require [appType]. Options: a) Use SAME application/credentials for all tasks b) Use DIFFERENT applications (requires unique identifiers)"

3. If SAME: User provides one application config with basic appTags

4. If DIFFERENT:

   • Prompt for unique identifier key (e.g., "purpose", "sourceSystem")

   • User provides separate application configs with unique identifier values

   • Update task appTags with matching unique identifiers

5. Build applications array (if needed) → get user confirmation

6. Additional Inputs (optional):

   • Ask user: "Do you want to specify a date range for this execution?"

   • From Date (format: YYYY-MM-DD) - optional

   • To Date (format: YYYY-MM-DD) - optional

7. Final confirmation → execute rule

8. If execution starts successfully → call fetch_execution_progress()

9. Rule Output File Display Process: a. Extract task outputs from execution results b. MANDATORY: Show output in this format: - TaskName: [task_name] - Files: [list of files] c. Ask: "View file contents? (yes/no)" d. If yes: Call fetch_output_file() for each requested file e. Display results with formatting

10. Rule Publication (optional):

• Ask user: "Do you want to publish this rule to make it available in ComplianceCow system? (yes/no)"

• If yes: Call publish_rule() to publish the rule

• If no: End workflow

UI DISPLAY REQUIREMENT:

• The file URL must ALWAYS be displayed to the user in the UI, allowing the user to view or download the file directly.

CRITICAL: rule_inputs MUST be the complete spec.inputsMeta__ objects with ALL original fields (name, description, dataType, repeated, allowedValues, required, defaultValue, format, showField, explanation) plus the 'value' field. DO NOT send trimmed objects with only name/dataType/value.

MANDATORY: The 'value' field content MUST also be copied to the 'defaultValue' field. Both fields must contain identical values. Example: if value="CSV", then defaultValue must also be "CSV".

Args: rule_name: The name of the rule to be executed. from_date: (Optional) Start date provided by the user in the format YYYY-MM-DD. to_date: (Optional) End date provided by the user in the format YYYY-MM-DD. rule_inputs: Complete spec.inputsMeta__ objects with ALL fields plus 'value' field, and 'defaultValue' set to same value as 'value'. applications: Application configuration details. For rules with only 'nocredapp' tasks, pass an empty list and the system will automatically use the hardcoded nocredapp application structure. is_application_data_provided_by_user (bool): Indicates whether application data was provided by the user. - Set to True if user provided or configured application details during execution. - Set to False if using nocredapp (empty applications list) or pre-existing applications.

Returns: Dict with execution results