Reimaginate.Orchestrator.DataHub 1.1.10

Reimaginate.Orchestrator.DataHub

DataHub-backed persistence and workflow definition integration for Orchestrator.

Use this package when checkpoints, workflow definitions, or workflow instances need to be stored through the existing DataHub model.

Workflow Actions

The package also includes portable DataHub workflow actions:

• DataHub.EscapeQueryStringValue
• DataHub.GetDataHubEntitiesById
• DataHub.GetDataHubEntitiesWhere
• DataHub.GetDataHubEntity
• DataHub.GetJobs
• DataHub.GetMergeMarker
• DataHub.GetSyncMarker
• DataHub.GetUpdatedDataHubEntities
• DataHub.PatchDataHubEntities
• DataHub.PatchDataHubEntity
• DataHub.RegisterSyncResults
• DataHub.RegisterWorkflowFailure
• DataHub.ReparentEntities
• DataHub.SubmitJob
• DataHub.UpdateDataHubEntities
• DataHub.UpdateSyncMarker

Register the action handlers in the customer host:

services.AddDataHubWorkflowActions(configuration);

If the host uses a custom workflow action resolver, scan this package's action assembly:

using Reimaginate.Orchestrator.Abstractions;
using Reimaginate.Orchestrator.DataHub.Actions;

[WorkflowActionResolver]
[ScanAssembly(typeof(DataHubWorkflowActionsMarker))]
public partial class WorkflowActionResolver : IWorkflowActionResolver;

DataHub.RegisterWorkflowFailure reads optional settings from Orchestrator:Actions:WorkflowFailureReporting.

Concurrent reparenting

DataHub.ReparentEntities accepts MaxConcurrency, a positive integer that defaults to 1. Existing workflows remain sequential. Set it to 4 to allow up to four record patches at once in either Field or CollectionItemField mode. The limit applies to one action invocation; callers running multiple actions concurrently must account for their combined load.

call: DataHub.ReparentEntities
with:
  EntityType: Booking
  FromDataHubEntityId: old-contact
  ToDataHubEntityId: surviving-contact
  WhereClause: x.Patron.EntityId='old-contact'
  ReparentMode: Field
  TargetPath: Patron.EntityId
  FetchAllPages: true
  MaxConcurrency: 4
  StopOnFirstFailure: true
  DispatchNotifications: false

Discovery still finishes before patching starts, and duplicate record IDs are patched once. FetchAllPages remains opt-in. Results and the completed/failed/ skipped ID lists retain discovery order even when patches finish out of order.

With StopOnFirstFailure: true, a reported failure prevents admission of more records. Work already admitted may still complete; the action awaits it and includes its outcomes. The existing continuation-suppression rules still apply when processing stops before all discovered records have been handled.

Cancellation also stops admission and awaits outstanding calls. The response reports DATAHUB_REPARENT_ENTITIES_CANCELLED, retains completed and uncertain submission details, and suppresses continuation using ContinuationSuppressedDueToFailure. Cancellation does not undo remote writes. There are no automatic patch retries. A zero or negative concurrency fails validation with INVALID_MAX_CONCURRENCY before any query is sent.