To address the significant growth in your namespace caused by Ens.AppData related to the usage of EnsLib.SQL.Snapshot in Business Process Language (BPL):

1. Issue with cleaning EnsLib.SQL.Snapshot:
   The snapshot data is not automatically cleaned during purge operations if it is used as a property within response messages. This results in the global ^Ens.AppData growing indefinitely. You can clean this manually in two steps:

   • Stop the production.
   • Run do ##class(Ens.Adapter).ClearStaticAppData("EnsLib.SQL.Snapshot") in the terminal of the relevant namespace to clear EnsLib.SQL.Snapshot data from ^Ens.AppData.
   • Execute SQL command TRUNCATE TABLE EnsLib_SQL.Snapshot to clean up EnsLib.SQL.Snapshot entries from the database1.

2. Defining %OnDelete Method:
   Implementing the %OnDelete method in the class holding the EnsLib.SQL.Snapshot property ensures proper cleanup of snapshot data during message deletion. Here is an example:

   Class ResponseMessage Extends Ens.Response  
   {
       Property SnapshotProp As EnsLib.SQL.Snapshot;
       ClassMethod %OnDelete(oid As %ObjectIdentity) As %Status [ Private, ServerOnly = 1 ]
       {
           set tSC = $$$OK
           set id = $$$oidPrimary(oid)    
           set obj = ..%OpenId(id)
           if (obj.SnapshotProp '= "") 
           {
               set tSC = ##class(EnsLib.SQL.Snapshot).%DeleteId(obj.SnapshotProp.%Id())
           }
           return tSC
       }
   }
   

   This ensures that associated snapshot data is deleted alongside its parent message1.

3. Alternative Approaches:

   • Avoid using EnsLib.SQL.Snapshot as a direct property. Instead, map the data to another object type (e.g., JSON string or custom class objects). This prevents EnsLib.SQL.Snapshot from being stuck in the global ^Ens.AppData1.
   • Periodically review and manage orphaned data or snapshots using implemented cleanup tasks in your production environment, ensuring your database remains manageable2.

By implementing these methods, you can reduce the growth in your namespace and ensure that the cleanup of EnsLib.SQL.Snapshot aligns with your application’s lifecycle. 12

Sources:

To count suppressed alert occurrences within the suppression window and obtain additional details such as the source component and total trigger count, you might need to implement customizations, as there is no direct, built-in method available.

1. Tracking Suppressed Alerts:

   • You can customize your alert-handling logic by integrating additional measures to count suppressed occurrences. For instance, you can use a custom global or table in your solution to track the count of these suppressed occurrences against each unique alert [[1]](https://community.intersystems.com/post/ensemble-suppressing-multiple-alerts-eg-naks-validation-etc-using-ensalert-process).

2. Using the IsRecentManagedAlert() Function:

   • The Ens.Alerting.Rule.FunctionSet.IsRecentManagedAlert() function can be used in your alert rules to suppress repeated alerts. Additionally, it can automatically add a reoccurs action to the associated managed alert that encapsulates the repeated occurrence history within the suppression window [[1]](https://community.intersystems.com/post/ensemble-suppressing-multiple-alerts-eg-naks-validation-etc-using-ensalert-process)[[2]](https://docs.intersystems.com/supplychain20251/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_alerts&ext=supplychain2025.1).

3. Custom Functions and Persistent Storage:

   • You may enhance alert handling by creating a business rule or a business process to extend logging and manipulation related to the alerts.
   • A custom function within your routing or handling logic could log every suppression event into a database table or global with fields for the component source, alert text, timestamp, and reoccurrence counts [[2]](https://docs.intersystems.com/supplychain20251/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_alerts&ext=supplychain2025.1).

4. Audit through the Managed Alerts Viewer:

   • The Managed Alert Viewer provides access to alert histories. The table displays detailed fields including reoccurrence actions recorded against alerts using the IsRecentManagedAlert() function [[3]](https://docs.intersystems.com/irisforhealth20251/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_alerts&ext=irisforhealth2025.1)[[2]](https://docs.intersystems.com/supplychain20251/csp/docbook/DocBook.UI.Page.cls?KEY=EMONITOR_alerts&ext=supplychain2025.1).

By combining the built-in capabilities with the customization above, you’ll be able to achieve greater observability and aggregated metrics for alerts during their suppression period.

Sources:

To create a task that triggers the execution of a Ens.BusinessService using the EnsLib.SQL.InboundAdapter, the general approach involves:

1. Task Definition: Using %SYS.Task.Definition to define task logic.
2. Business Service: Ensure proper configuration of the business service to use the SQL adapter.
3. Trigger Mechanism: Integrating the task and service for seamless execution.

Task Implementation:

Here’s an example approach that can address your specific use case:

• Extend %SYS.Task.Definition for custom task logic.
• Use the OnTask() method to instantiate and invoke the business service.

Class Sample.Task.TriggerSQLServiceTask Extends %SYS.Task.Definition
{
    /// The name of the Business Service to be executed
    Property BusinessServiceName As %String [Required];

    Method OnTask() As %Status
    {
        // Create BusinessService object
        #dim businessServiceInstance As Ens.BusinessService
        set tSC = ##class(Ens.Director).CreateBusinessService(..BusinessServiceName, .businessServiceInstance)
        $$$ThrowOnError(tSC)

        // Invoke the service's OnTask or similar method
        quit businessServiceInstance.OnTask()
    }
}

You define a BusinessServiceName property in the task class, which indicates the service to be triggered. When the task is executed, this task will dynamically create and execute the specified business service.

Scheduling the Task:

The service can be linked with the system’s task scheduler by defining the task scheduling parameters. The parameters will allow daily or specific-time execution of the query.

Key Considerations for Your Business Service:

• Configure the EnsLib.SQL.InboundAdapter to specify the SQL query and other relevant settings (e.g., DSN or database connectivity details).

• Use the OnProcessInput() method in the service to handle any incoming snapshots or inputs from the SQL query results. For example:

  Method OnProcessInput(pInput As EnsLib.SQL.Snapshot, pOutput As %RegisteredObject) As %Status
  {
      set req = ##class(OSU.Workday.Messages.WorkdayTerminations).%New()
      set req.EMPLID = pInput.Get("EMPLID")
      // Add additional field mappings
      ...
      quit ..SendRequestSync("TargetConfigName", req)
  }
  

Other Options:

If you do not want to handle SQL execution directly in the task but let the Business Service control it:

• Ensure the service is appropriately configured to handle its SQL logic independently.
• The task simply activates the service for its execution, relying on the internal adapter setup for query execution.

For more tailored implementation details, please refer to the examples provided in the source where tasks and services interact:

• Custom SQL adapters and Business Service connections 1.
• Methods for defining task-triggered services 21.

Sources: