If-Then Rules

A key concept in aeppic is that every piece of data, every action should be manually executable to prevent users from getting stuck due to missing or incomplete automation provided the user has the appropriate permissions. However, doing everything manually can be repetitive and error-prone. This is where business rules come in.

Business rules are based on an 'If-Then' principle. Some have seens similar concepts in global automation platforms like If-Then-That or Zapier. In aeppic this is built-in and always has been as a first class concept. Business rules are defined in the data model and are executed whenever a document is changed and a rule's trigger matches.

Key Concept

A business rule is defined as a document of type Business Rule and consists of triggers and actions that execute when specific conditions are met.

How Business Rules Work

Trigger Context

Business rules can be triggered in two contexts:

1. User Context:

   • Triggered by user actions (executed server or client side)
   • Run with the user's permissions
   • Can operate offline with local synchronization

2. Server Context:

   • Can run under a server account with potentially elevated permissions
   • Can access server-only resources
   • Can keep local state independent of the model for tracking information WIP

Write-Locked Environment

Business rules operate in a controlled, write-locked environment:

// Example Business Rule Action
const document = await Aeppic.edit(documentId)
document.increment('counter')
Aeppic.save(document) // Changes are queued and only executed when the action returns without exception

Important

Queries within a business rule reflect the pre-change state of the data model. Only direct document access shows pending changes.

Deterministic Execution

Business rules are designed for reproducible, deterministic execution:

• Access to time and environment variables is controlled
• Actions are logged for debugging
• Failed rules can be replayed in aeppic 4

Future Feature

aeppic 4 will introduce enhanced debugging capabilities, allowing developers to replay failed business rules with identical inputs.

Chaining Rules

Business rules can trigger other rules, enabling complex workflows:

1. Rule A creates a document
2. Rule B responds to the creation
3. Rule C processes the final state

Offline Support WIP

Business rules that run in user context support offline operation:

• Changes are stored locally first
• Synchronization occurs when online
• Conflicts are resolved automatically

Note

Server-context rules only execute when the system is online.

Security Considerations

Business rules inherit security constraints:

• User-context rules respect user permissions
• Server-context rules can bypass normal security
• Actions are logged for audit purposes

Integration with Stamping

Business rules often use stamping for workflow management:

// Example: Stamp a Document in a Business Rule
const doc = await Aeppic.edit(documentId)
const checkedEmailStamp = await Aeppic.get('my-checked-email-stamp-id')

await Aeppic.stamp(doc, {
  type: 'processed',
  checkedEmailStamp,
  workflowUid: 'email-processing',
  additionalDataDocument: {
    f: { id: 'additional-email-stamp-info-id', v: 'initial' }
    data: { virusScan: 'pending' }
  }
})

Best Practices

1. Keep Rules Focused:

   • One rule, one responsibility
   • Chain rules for complex workflows

2. Handle Errors:

   • Rules should be idempotent
   • Use stamps to track progress

3. Document Dependencies:

   • List required forms
   • Document expected triggers

Testing

Test business rules with various document states to ensure reliable execution.