Maestro Overview

Maestro Framework Examples
Good Use Cases
- Creating web load or stress tests (using request configuration exported from Postman)
- Writing books or pieces of apps using AI
- Performing research using AI
- Orchestrating data transfers or migrations
- Publishing to online or social media platforms
- Automatic invoicing
- Administrative automation
- Keeping servers up to date
- Orchestrating inter-system communications
- Orchestrating multiple QA or benchmark tests

Poor Use Cases
- Creating websites
- Creating REST APIs
- Creating any app with an interactive user interface

---
Maestro Framework Technical Overview
Definitions
- Sensitive keys: Can't be written to disk.
- *Path: These are JSON paths always.
- State: Lives in memory as a dictionary and is written to / read from JSON.
- Constant: Lives in a file in Constants folder.
  All files from this folder are read at startup (filename is the constant name) and are immutable during app run.
- Errors: First error is written to "appError" key in the state and persisted to a local file, appError.json.
  An error will terminate the application flow.

Templates
- #@@ to reference something
- If reference is to an array, levelNTemplate (starting with N=2) will be used to process each object in the array, where N = the level inside the nested structure
- Strings are encoded according to the file format, e.g. HTML or CSV; use TXT to avoid encoding

Data
- $.dataConnections: This key defines each connection as an object with a key, e.g. "dataConnections": { "key1": { ... } }
- $.dataConnections.X.systemType: "" (supported systems currently: MemorySql, SqlServer, MockData (Select will read from .csv))
- $.dataConnections.X.connString: Depends on the systemType (such as SqlServer), not required for MemorySql, local folder path for MockData (current folder if not given)
- "connPath": Path relative to $.dataConnections where the connection is defined.
- Session is created on first interaction in Block. Session expires and is removed on Block end. Sessions are per-connection.
- "parameters": { "schema": { "col": "type", ... }, "data": { "col": "value", ... } }
- "schema": { "col": "type", ... } where "type" can be "string", "integer", "number", or "date"
- "timeout": (milliseconds) optional; default 900 seconds
- $.customDataProviders: Key-value pairs describing system type and .NET namespace/assembly (DLL) of implementation, e.g. { "MySQL": "YourCompany.YourLibrary" }
  - Custom data provider must implement Dacris.Maestro.Data.IDataRepository and have a no-parameter constructor; use BaseDataRepository for common functionality
  - Name of class should be DataRepository and should be public

Storage
- $.storageLocations: This key defines each storage location as an object with a key, e.g. "storageLocations": { "key1": { ... } }
- $.storageLocations.X.systemType: "" (supported systems currently: Local, SFTP)
- $.storageLocations.X.serverHost: Host name for SFTP
- $.storageLocations.X.user: User name for SFTP
- $.storageLocations.X.secretKey: Password key for SFTP
- $.storageLocations.X.port: Port number for SFTP
- Each key in storageLocations acts as a reusable file path prefix (e.g. key1:some/storage/path)
- $.customStorageProviders: Key-value pairs describing system type and .NET namespace/assembly (DLL) of implementation, e.g. { "Azure": "Dacris.AzureStorage" }
  - Custom storage provider must implement Dacris.Maestro.Storage.IFileProvider and have a constructor which takes two arguments (Interaction i, string prefix)
  - Name of class should be FileProvider and should be public

AI
- $.chatSettings: This key defines the chat configuration as an object with a key, e.g. "myChatConfig"
- $.chatSettings.X.systemType: "" (supported systems currently: Ollama, OpenAI [coming soon])
- $.chatSettings.X.port: Ollama port (omit for default)
- $.chatSettings.X.model: Ollama model
- $.chatSettings.X.secretKey: (currently unused; for OpenAI)

Mocking
- Set "mock":"true" at the root of your State.
- Create "Mock.json" with State key overrides for any dataConnections and storageLocations you use, as well as any other path overrides like urls for HTTP requests.
- MockState.json will be persisted instead of State.json. This will be used when in mock mode to read/write state instead of State.json.
- For http requests, use file: as a Url prefix for a static file.
- For storage, path structure may need to change if mock vs non-mock (see sftp app example).