T40.2: ImplementCCR Routines and CCR Event Handlers

Knowledge Review - InterSystems CCR Technical Implementation Specialist

1. Identify Use Cases for ImplementCCR Routines and CCR Event Handlers

Key Points

  • ImplementCCR routines: Per-CCR custom logic executed automatically during ItemSet deployment after importing and compiling all code
  • CCR Event Handlers: Per-System custom logic executed during the ItemSet load process at specific hook points
  • Tier 1 Transport Load Flow: Defines the execution order -- Event Handler ItemSetAfterLoadToOS(), then item import/compile, then ImplementCCR routine, then Event Handler ItemSetAfterLoadToNS()
  • Built-in functions: CCR provides environment-aware functions ($$IsLIVE, $$Env, $$EnvName, $$Sys, $$Org) usable in both ImplementCCR routines and custom code
  • Write statements: Output from Write statements in ImplementCCR routines and Event Handlers is directed to the Transport Log

Detailed Notes

ImplementCCR Routines

ImplementCCR routines provide per-CCR custom logic that executes automatically when an ItemSet is deployed to any environment (TEST, LIVE, or any peer environment). They are ideal for tasks that are specific to a particular change and need to run once during deployment.

Common use cases include:

  • Data migration: Running SQL statements or ObjectScript code to transform or migrate data as part of a code change
  • Configuration updates: Setting global values, updating lookup tables, or adjusting system parameters that accompany a code change
  • Cache clearing: Purging cached data that may be invalidated by the new code
  • One-time initialization: Creating initial data records or setting up required structures for new functionality
  • Environment-specific behavior: Using built-in functions like $$IsLIVE^%buildccr to prevent emails from being sent to actual users from BASE or TEST, or $$Env^%buildccr to display the environment name in UI headers or email footers

CCR Event Handlers

CCR Event Handlers provide per-System custom logic that executes during every ItemSet deployment for that system. Unlike ImplementCCR routines (which are specific to a single CCR), Event Handlers run for all CCRs within a system.

To create a CCR Event Handler: 1. Create a class that extends %Studio.SourceControl.CCREventHandler 2. Implement callback methods based on the method stubs in the parent class 3. Register the handler by setting: Set ^SYS("SourceControl","EventHandler","Class")="MyClassName"

Key callback methods include:

  • ItemSetAfterLoadToOS(): Executed after ItemSet files are loaded to the source workspace (file system) but before they are imported into the namespace
  • ItemSetAfterLoadToNS(): Executed after all items have been imported into the namespace, compiled, and the ImplementCCR routine (if any) has run

Common Event Handler use cases include:

  • Production restart: Automatically restarting or updating a production after any code deployment to pick up new business logic
  • Notification: Sending deployment notifications to operations teams so they are aware of changes reaching an environment
  • Logging: Recording deployment events in a custom audit table for compliance and traceability
  • Post-deployment validation: Running verification checks after every ItemSet load to confirm the environment is functioning correctly
  • Environment cleanup: Clearing cached configuration data, temporary globals, or stale references that may not be covered by the ImplementCCR routine

Key Difference: Per-CCR vs Per-System Scope

The fundamental distinction between ImplementCCR routines and Event Handlers is their scope:

  • ImplementCCR routines are tied to a specific CCR ID. They execute only when an ItemSet for that particular CCR is deployed. This makes them ideal for one-time tasks associated with a specific change, such as data migration or configuration updates that accompany new code.
  • CCR Event Handlers are tied to the System. They execute for every ItemSet deployment across all CCRs in that system. This makes them ideal for recurring tasks that should happen with every deployment, such as production restarts or deployment notifications.

Both mechanisms can coexist. During a single ItemSet deployment, the Event Handler runs at its designated hook points and the ImplementCCR routine runs at its designated point in the sequence.

Tier 1 Transport Load to Namespace Flow

When a Tier 1 ItemSet is deployed to an environment, the following sequence occurs:

1. ItemSetAfterLoadToOS() -- If a CCR Event Handler is configured, this method executes first (after files reach the workspace) 2. Item loading -- Items in Tier 1 subfolders (/cls, /cspapp, /inc, /prj, /rtn) are automatically loaded into the namespace 3. Project compilation -- All items are added to a project named after the ItemSet and compiled in the proper order 4. ImplementCCR routine execution -- If an ImplementCCR routine exists for the CCR, it is executed 5. ItemSetAfterLoadToNS() -- If a CCR Event Handler is configured, this method executes last

Write statements in both ImplementCCR routines and Event Handler methods are directed to the Transport Log, which can be viewed and downloaded from the CCR Perforce Details section.

CCR Built-in Functions

CCR provides several built-in functions in the %buildccr routine that allow code to vary its behavior based on the current environment:

FunctionPurposeExample Use Case
$$IsLIVE^%buildccrReturns whether the current environment is LIVEPrevent test emails from being sent to real users in BASE/TEST
$$Env^%buildccrReturns the environment type (BASE, TEST, UAT, LIVE)Display environment in email footers or UI headers
$$EnvName^%buildccrReturns the environment namePerform customized logic for specific environments (e.g., TRAIN as a peer to TEST)
$$Sys^%buildccrReturns the SystemCodeInclude system identification in error logs
$$Org^%buildccrReturns the OrganizationInclude organization details in email alerts to centralized monitoring

These functions can be used in any ObjectScript code, not just ImplementCCR routines, making them valuable for writing environment-aware production code.

---

Documentation References

2. Create ImplementCCR Routine Using Correct Naming Convention

Key Points

  • Naming convention: Must be exactly `ImplementCCR.` (case-sensitive)
  • Example: For CCR ID "BEST0001", the routine must be named `ImplementCCR.BEST0001`
  • Automatic execution: Client Tools automatically run the routine during ItemSet deployment if it exists
  • Execution timing: Runs after importing and compiling all code in the ItemSet
  • Must match CCR: The CCR ID in the routine name must match the CCR to which it is uploaded; uploading ImplementCCR.BEST12345 to CCR BEST6789 will produce an error

Detailed Notes

Naming Convention

The naming convention for ImplementCCR routines is strict and case-sensitive:

  • Format: ImplementCCR.<CCR_ID>
  • The prefix "ImplementCCR" must use exact capitalization (capital I, capital C, capital C, capital R)
  • The CCR_ID portion must exactly match the CCR record identifier
  • Examples:
  • CCR ID BEST0001 requires routine name ImplementCCR.BEST0001
  • CCR ID ISCX12943 requires routine name ImplementCCR.ISCX12943
  • CCR ID TRPHS0042 requires routine name ImplementCCR.TRPHS0042

The naming convention is validated during the bundle and upload process. If you attempt to upload a routine named ImplementCCR.BEST12345 to a CCR with ID BEST6789, the system will produce an error because the CCR ID in the routine name does not match the target CCR.

Creating the Routine

To create an ImplementCCR routine:

1. Open the IDE (Studio or VS Code) connected to the BASE environment 2. Create a new ObjectScript routine (MAC routine type) 3. Name it using the exact convention: ImplementCCR.<CCR_ID> 4. Write the implementation logic as standard ObjectScript code 5. Use Write statements for output that should appear in the Transport Log 6. Save and compile the routine 7. When prompted, add the routine to source control 8. Include the routine in the ItemSet bundle along with other changed items

Execution Behavior

When an ItemSet is deployed to any environment:

  • The Client Tools check whether an ImplementCCR routine matching the CCR ID exists in the ItemSet
  • If found, the routine is executed automatically after all other items in the ItemSet have been imported and compiled
  • The routine runs in the target namespace of the deployment
  • All Write output is captured in the Transport Log
  • The routine executes on every deployment of that ItemSet (TEST, LIVE, and any peer environments)

Best Practices

  • Test in BASE: Verify the ImplementCCR routine works correctly in BASE before progressing the CCR to ensure it will not fail during deployment to TEST or LIVE
  • Use built-in functions: Leverage $$Env^%buildccr and $$IsLIVE^%buildccr to vary behavior by environment when needed (e.g., skip sending real notifications from BASE or TEST)
  • Keep it focused: The routine should contain only the logic needed for this specific CCR's deployment; do not include logic that belongs in Event Handlers or in the application code itself
  • Document in Implementation Plan: If the ImplementCCR routine performs significant actions (such as data migration or configuration changes), document this in the CCR's Implementation Plan so reviewers and deployers are aware
  • Handle errors gracefully: Include error handling (Try/Catch or $ZTrap) to prevent deployment failures from unhandled errors in the routine
  • Idempotent design: Where possible, design the routine so it can be safely re-executed without causing duplicate data or other side effects, since the same ItemSet may be deployed multiple times during troubleshooting

---

Documentation References

Exam Preparation Summary

  1. ImplementCCR routines are per-CCR custom deployment logic; CCR Event Handlers are per-System and run for every ItemSet deployment in that system
  2. The naming convention is case-sensitive: `ImplementCCR.` -- the CCR_ID must exactly match the target CCR record
  3. Execution order during ItemSet deployment: Event Handler ItemSetAfterLoadToOS() -> item import and compile -> ImplementCCR routine -> Event Handler ItemSetAfterLoadToNS()
  4. ImplementCCR routines execute automatically during ItemSet deployment if they exist; no manual invocation is required
  5. CCR Event Handlers extend `%Studio.SourceControl.CCREventHandler` and are registered via the `^SYS("SourceControl","EventHandler","Class")` global
  6. Write statements in both ImplementCCR routines and Event Handlers are directed to the Transport Log
  7. Built-in functions ($$IsLIVE, $$Env, $$EnvName, $$Sys, $$Org from %buildccr) allow environment-aware behavior in any ObjectScript code
  8. Uploading an ImplementCCR routine with a mismatched CCR ID will produce an error during bundle and upload validation

Report an Issue