-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #168 from ConductionNL/feature/CONNECTOR-52/cloud-…
…events Rules logic and cloud events standard
- Loading branch information
Showing
57 changed files
with
5,544 additions
and
67 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
# Synchronization | ||
|
||
Synchronization is a core feature that enables data transfer between different systems and APIs. Here's how it works: | ||
|
||
## Overview | ||
- Synchronizations define how data should be synchronized between a source and target system | ||
- Each synchronization has a source configuration (where to get data from) and target configuration (where to send data to) | ||
- The synchronization process handles pagination, data mapping, and maintaining sync state | ||
|
||
## Key Components | ||
|
||
### Source Configuration | ||
- Defines where to fetch data from (API endpoint, database etc) | ||
- Specifies how to map source data to target format (incomming data) | ||
- Specifies how to locate objects in the response using resultsPosition: | ||
- `_root`: Uses the entire response body as the objects array | ||
- Dot notation (e.g. `data.items`): Extracts objects from a nested path | ||
- Common keys (`items`, `result`, `results`): Automatically checks these standard locations | ||
- Custom path: Specify any JSON path to locate the objects | ||
- Configures pagination settings (paginationQuery) | ||
- Can include conditions to filter which objects to sync using JSON Logic | ||
- Source type can be set to API or other supported types | ||
- Source ID mapping allows specifying position of IDs in source objects | ||
- Optional endpoint configuration for fetching data | ||
|
||
### Target Configuration | ||
- Defines where to send synchronized data | ||
- Specifies how to map target data to source format (outgoing data) | ||
- Handles create/update/delete operations | ||
- Target type can be Register/Schema or other supported types | ||
- Target ID and schema selection for Register/Schema targets | ||
- Target source mapping for data transformations | ||
|
||
### Synchronization Contracts | ||
- Tracks the sync state for each individual object | ||
- Stores origin ID and target ID mappings | ||
- Maintains hashes to detect changes | ||
- Logs synchronization events and errors | ||
|
||
## Process Flow | ||
1. Fetch objects from source system with pagination | ||
2. Filter objects based on configured conditions | ||
3. Create/update synchronization contracts for each object | ||
4. Transform data according to mapping rules | ||
5. Write objects to target system (POST/PUT/DELETE) | ||
6. Update contract status and hashes | ||
7. Handle any follow-up synchronizations | ||
|
||
## Error Handling | ||
- Rate limiting detection and backoff | ||
- Logging of failed operations | ||
- Contract state tracking for retry attempts | ||
|
||
The synchronization system provides a robust way to keep data in sync across different systems while maintaining state and handling errors gracefully. | ||
|
||
## Form Configuration | ||
The synchronization form allows configuring: | ||
|
||
- Name: Descriptive name for the synchronization | ||
- Description: Optional details about the synchronization | ||
- Conditions: JSON Logic conditions for filtering objects | ||
- Source Configuration: | ||
- Source Type: API or other supported types | ||
- Source ID: Selection of configured source | ||
- Source hash mapping: Hash configuration | ||
- Source target mapping: Data mapping rules | ||
- Position of ID in source object (optional) | ||
- Position of results in source object (optional) | ||
- Custom endpoint for data fetching (optional) | ||
- Target Configuration: | ||
- Target Type: Register/Schema or other types | ||
- Target ID: Selection of target system | ||
- Register and Schema selection for Register/Schema targets | ||
- Target source mapping: Data transformation rules | ||
- Test sync option to validate configuration | ||
|
||
![alt text](image.png) |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
# Rules | ||
|
||
Rules are components that can be associated with endpoints to add additional functionality. Based on the current codebase, rules are stored as string IDs and can be attached to multiple endpoints. | ||
|
||
## Adding Rules to Endpoints | ||
|
||
Rules can be added to endpoints through the AddEndpointRule modal component. The process works as follows: | ||
|
||
1. Select a rule from the available rule options dropdown | ||
2. The rule ID is added to the endpoint's `rules` array property | ||
3. The endpoint is updated with the new rule association | ||
4. On success, the modal closes automatically after 2 seconds | ||
|
||
## Rule Properties | ||
|
||
Rules have several key properties that define their behavior: | ||
|
||
- uuid: A unique identifier string for the rule | ||
- name: The display name of the rule | ||
- description: A detailed description of the rule's purpose | ||
- action: Specifies when the rule triggers (create, read, update, delete) | ||
- timing: Controls if rule runs 'before' or 'after' the action (defaults to 'before') | ||
- conditions: JSON Logic format conditions that determine when rule applies | ||
- type: The rule type (mapping, error, script, synchronization, authentication, download, upload, locking) | ||
- configuration: Type-specific configuration stored as JSON | ||
- order: Integer determining execution order when multiple rules exist | ||
|
||
The properties work together to define: | ||
|
||
1. When the rule executes (action + timing) | ||
2. Under what conditions it runs (conditions) | ||
3. What functionality it provides (type + configuration) | ||
4. The sequence of execution (order) | ||
|
||
Rules are stored in a structured format but referenced by endpoints using their UUID strings in an array format. | ||
|
||
## Rule Implementation | ||
|
||
The current implementation shows: | ||
|
||
- Rules are managed through a dedicated API endpoint at `/api/rules` | ||
- Rules can be retrieved and managed through the Rules resource controller | ||
- Rule IDs are stored and validated as strings within endpoints | ||
- The endpoint entity ensures rules are always stored as an array | ||
|
||
## Rule Types | ||
|
||
### Authentication Rules | ||
|
||
Authentication rules control access to endpoints by validating user credentials and permissions. Configuration options include: | ||
|
||
- type: The authentication method to use | ||
- basic: Basic HTTP authentication | ||
- jwt: JSON Web Token authentication | ||
- jwt-zgw: ZGW-specific JWT authentication | ||
- oauth: OAuth 2.0 authentication | ||
- users: Array of specific users allowed to access the endpoint | ||
- groups: Array of user groups allowed to access the endpoint | ||
|
||
### Download Rules | ||
|
||
Download rules handle file access and retrieval. Configuration includes: | ||
|
||
- fileIdPosition: Specifies the position of the file ID in the URL path | ||
- Automatic validation of user access rights to requested files | ||
|
||
### Upload Rules | ||
|
||
Upload rules manage file upload functionality and restrictions. Configuration includes: | ||
|
||
- path: The target directory path for uploaded files | ||
- allowedTypes: Comma-separated list of allowed file extensions (e.g., jpg,png,pdf) | ||
- maxSize: Maximum allowed file size in megabytes | ||
|
||
### Locking Rules | ||
|
||
Locking rules provide exclusive access control for resources. Configuration includes: | ||
|
||
- action: The locking operation to perform | ||
- lock: Lock a resource for exclusive access | ||
- unlock: Release a previously locked resource | ||
- timeout: Duration in minutes before the lock automatically expires | ||
|
||
## Rule Validation | ||
|
||
When adding rules to an endpoint: | ||
|
||
- The rules array is initialized if it doesn't exist | ||
- Existing rule IDs are converted to strings | ||
- New rule IDs are validated before being added | ||
- The endpoint is revalidated after rule changes | ||
|
||
## Error Handling | ||
|
||
The rule addition process includes: | ||
|
||
- Validation that a rule is selected before saving | ||
- Error catching and display if the save fails | ||
- Loading state management during the save process | ||
- Success/error message display to the user |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.