Xenhey.BPM.Core.Net8 1.0.89

.NET 8.0 This package targets .NET 8.0. The package is compatible with this framework or higher.
There is a newer version of this package available.
See the version list below for details. 
dotnet add package Xenhey.BPM.Core.Net8 --version 1.0.89
                    


                    

                
NuGet\Install-Package Xenhey.BPM.Core.Net8 -Version 1.0.89
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package. 
<PackageReference Include="Xenhey.BPM.Core.Net8" Version="1.0.89" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Xenhey.BPM.Core.Net8" Version="1.0.89" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Xenhey.BPM.Core.Net8" />
                    


                            Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package. 
paket add Xenhey.BPM.Core.Net8 --version 1.0.89
                    


                    

                
#r "nuget: Xenhey.BPM.Core.Net8, 1.0.89"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package. 
#:package Xenhey.BPM.Core.Net8@1.0.89
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package. 
#addin nuget:?package=Xenhey.BPM.Core.Net8&version=1.0.89
                    


                            Install as a Cake Addin
                        

                    

                
#tool nuget:?package=Xenhey.BPM.Core.Net8&version=1.0.89
                    


                            Install as a Cake Tool

Xenhey — From Design Meetings to Live Collaboration

Xenhey fundamentally changes how integration projects are designed, reviewed, and delivered. Instead of long meetings debating specifications, APIs, and implementation details, Xenhey provides a shared, real-time workspace where outcomes are built, reviewed, and published live.

At its core, Xenhey includes tooling that allows end clients—not just developers—to create, edit, and publish content directly to RESTful APIs in multiple formats:

  • HTML (UI fragments, forms, views)
  • JSON (schemas, payloads, rules, configurations)
  • XML (legacy or standards-based integrations)
  • Plain text (templates, instructions, metadata)

Below is a clear, executive-ready “Before vs After Xenhey” comparison you can use in a README, sales deck, or client proposal. It’s written to highlight behavioral change, delivery speed, and collaboration impact—not just tooling.

🚦 Before vs After Xenhey

How Integration Projects Change with Xenhey

Dimension Before Xenhey After Xenhey
Client Involvement Clients review static docs, slides, or mockups Clients work directly in a shared live workspace
Meetings Design-heavy, abstract discussions Working sessions with real-time updates
Artifacts Specs, PDFs, tickets, emails Live HTML, JSON, XML, and text artifacts
Feedback Loop Days or weeks between feedback and changes Immediate, in-session feedback and updates
Change Process Raise a ticket → wait → redeploy Edit → publish → see results instantly
Source of Truth Spread across docs, repos, and messages Centralized workspace with live state
Client Confidence Based on explanations and promises Based on visible, working outputs
Iteration Speed Slow, batch-oriented Fast, continuous, real-time
Rework Risk High due to misinterpretation Low due to shared visibility
Delivery Timeline Extended by handoffs and clarifications Compressed through live collaboration
Developer Load High (constant translation of requirements) Focused on high-value engineering
Governance & Audit Manual tracking of changes Built-in versioning and traceability
API Exposure Implemented late in the cycle Available and testable from day one
Client Ownership Passive consumer Active co-creator

🧩 Integration Approach Comparison

Area Before: Direct Azure Service Integration After: Workflow-Driven Azure Connectors (Xenhey)
Connection Model Custom SDK code per service (SB, EH, SQL, ADX, Storage) Unified connector model abstracted by workflows
Implementation Effort High – each Azure service requires bespoke code Low – connectors are prebuilt and reused
Workflow Orchestration Hard-coded logic scattered across services Centralized, declarative workflows
Change Impact Code changes + redeployments Configuration & rule updates only
Onboarding New Azure Services Weeks of design, coding, testing Hours or days via connector configuration
Consistency Across Services Varies by developer/team Enforced by the runtime
Error Handling Manually implemented per service Standardized retry, DLQ, and compensation
Security Model Reimplemented per integration Centralized (Managed Identity, x-api-key)
Authentication Logic Duplicated across codebases Handled once by the runtime
Environment Drift High risk across dev/test/prod Minimal—config-driven
Testing Strategy Mock-heavy, service-specific Workflow-level testing
Governance & Policy Enforced informally Built-in and centralized
Auditability Fragmented logs across systems End-to-end workflow traceability
Observability Logs and metrics per service Unified telemetry and correlation
Reporting Custom dashboards per system REST-first reporting layer
Client Visibility Limited to post-deployment Real-time via shared workspace
Iteration Speed Slow, batch-based Fast, real-time
Meeting Focus Design & implementation debates Live updates to workflows
Risk of Rework High due to misalignment Low due to shared execution view
Total Cost of Ownership High (engineering + ops) Lower through reuse and standardization

You’re essentially positioning Xenhey as:

A configuration-driven orchestration runtime that can plug into OpenAI + Azure OpenAI without rewriting application code.

Let’s break this down clearly.

🧠 Xenhey + OpenAI / Azure OpenAI Integration Model

Instead of hardcoding prompt logic in application code, Xenhey:

  • Accepts user input (UI, API, file, event)

  • Applies transformation templates

  • Maps to OpenAI schema (Structured Output / JSON Schema)

  • Sends to OpenAI or Azure OpenAI

  • Routes the response to:

    • Blob
    • Service Bus
    • SQL
    • Event Hub
    • REST callback
    • Or chained workflow

This is dramatically different from traditional integration.

🔥 Xenhey vs Traditional OpenAI Integration

Category Traditional Integration Xenhey Config-Driven Integration
Prompt Handling Hardcoded in C#/Python Defined in JSON workflow
Model Switching Code change required Change via configuration
Schema Enforcement Manual JSON parsing Built-in structured schema mapping
Azure OpenAI Support Separate SDK setup Config toggle for Azure/OpenAI
API Key Management In app code Externalized via config / vault
Logging Custom implementation Centralized workflow logging
Multi-Model Support Custom per model Configurable model per step
Response Routing Custom logic Workflow process chain
Versioning Code branch Workspace version control
Governance App-specific Policy-driven workflow
Reusability Limited Template-driven reuse
Business User Updates Requires dev Update via workspace
Security App-layer Runtime-level
Retry Logic Manual Config-based
Observability App logs Unified execution reporting

🏗 Xenhey OpenAI Integration Architecture (Conceptual)

User Prompt
    ↓
Xenhey Intake Process
    ↓
TransformationProcess
    ↓
Schema Mapping (JSON Schema)
    ↓
OpenAI / Azure OpenAI Process
    ↓
Response Routing Process
    ↓
Blob / SQL / Service Bus / API

🔹 Example Xenhey OpenAI Configuration (Conceptual)

{
  "Key": "OpenAIProcess",
  "Type": "Xenhey.BPM.Core.Net8.Processes.OpenAIProcess",
  "IsEnable": "true",
  "DataFlowProcessParameters": [
    {
      "Key": "Provider",
      "Value": "AzureOpenAI"
    },
    {
      "Key": "Model",
      "Value": "gpt-4o"
    },
    {
      "Key": "Endpoint",
      "Value": "https://my-azure-openai.openai.azure.com/"
    },
    {
      "Key": "ApiKey",
      "Value": "AzureOpenAIKey"
    },
    {
      "Key": "UseStructuredOutput",
      "Value": "true"
    },
    {
      "Key": "SchemaName",
      "Value": "CreditResponse"
    }
  ]
}

No C# code changes required.

🧩 Schema-Based Prompt Mapping (OpenAI Structured Output)

Instead of free-text parsing, Xenhey can map user prompt → schema like:

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "CreditResponse",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "Term": { "type": "string" },
          "CreditScore": { "type": "string" },
          "AnnualIncome": { "type": "string" }
        },
        "required": ["Term","CreditScore","AnnualIncome"]
      }
    }
  }
}

Xenhey can:

  • Store schema in workspace
  • Apply schema dynamically
  • Validate AI response before routing

⚡ Key Differentiators

1️⃣ Multi-Provider Ready

Provider Traditional Xenhey
OpenAI Custom SDK Config switch
Azure OpenAI Separate endpoint logic Configurable provider
Future LLMs Rewrite integration Add provider config

2️⃣ Prompt as Configuration

Traditional:

var response = await client.ChatCompletionAsync(...);

Xenhey:

{
  "PromptTemplate": "Evaluate the loan based on {{AnnualIncome}}..."
}

No redeploy.

3️⃣ Enterprise Governance

With Xenhey you can:

  • Restrict model types
  • Enforce schema outputs
  • Log prompts + completions
  • Apply retry policy
  • Route low confidence responses to review queue

Traditional approach requires building all of this.

🔐 Enterprise Advantages (Especially in Regulated Industries)

Since you work in finance + insurance use cases, this matters:

Requirement Traditional Effort Xenhey Benefit
SOX logging Custom logging Built-in execution audit
Prompt Versioning Git branches Workspace version
Model Drift Control Manual Centralized config
PII Controls App logic Filter process in workflow
Token Cost Monitoring Custom tracking Execution metadata
Approval Workflows External build Chain process

🧠 Real Enterprise Use Cases

🔹 Insurance

  • Claim narrative → structured fraud risk schema
  • Adjuster notes → risk classification
  • Auto claim summary → SQL persistence

🔹 Finance

  • Loan document → structured decision
  • Natural language credit queries → SQL filter mapping
  • Portfolio risk analysis via schema enforcement

🔹 SMB SaaS

  • Customer support chat → structured ticket object
  • Product feedback → sentiment + classification schema

🎯 Strategic Positioning

Xenhey is not “calling OpenAI.”

It is:

An LLM Orchestration Layer with governance, schema enforcement, routing, and workflow automation.

🧠 Architectural Shift

Before

  • Azure services are wired directly into application code
  • Business logic and integration logic are tightly coupled
  • Every new requirement introduces code changes
  • Teams spend time discussing design instead of validating outcomes

After

  • Azure services are invoked as workflow steps
  • Integration logic is externalized and reusable
  • Changes are made through rules and configuration
  • Teams focus on live collaboration and results

📈 Business & Delivery Impact

Dimension Before After
Time to First Integration Slow Fast
Change Turnaround Days–Weeks Minutes–Hours
Client Confidence Moderate High
Developer Burn High Reduced
Delivery Predictability Low High
Platform Scalability Limited by code Scales via configuration

🏁 Executive Summary

Moving from direct Azure service integrations to workflow-driven connectors transforms Azure from a collection of APIs into a cohesive integration platform. Xenhey standardizes connectivity, accelerates delivery, and turns integration work into a collaborative, real-time process rather than a prolonged implementation cycle.

🧩 Why This Matters Strategically

Xenhey doesn’t just optimize integration workflows. It changes how teams and clients collaborate:

From “tell me what you want” to “let’s build it together—right now.”

That shift:

  • Reduces project risk
  • Improves stakeholder confidence
  • Makes delivery more predictable
  • Elevates the role of the platform from tool to enabler

Xenhey replaces design-heavy integration projects with real-time, collaborative delivery—turning meetings into live working sessions and clients into active contributors.

Product Compatible and additional computed target framework versions.
.NET net8.0 is compatible.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed.  net9.0 was computed.  net9.0-android was computed.  net9.0-browser was computed.  net9.0-ios was computed.  net9.0-maccatalyst was computed.  net9.0-macos was computed.  net9.0-tvos was computed.  net9.0-windows was computed.  net10.0 was computed.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
1.0.96 79 5/12/2026
1.0.95 75 5/12/2026
1.0.94 85 5/12/2026
1.0.93 150 3/4/2026
1.0.92 113 3/3/2026
1.0.91 107 3/3/2026
1.0.90 180 2/23/2026
1.0.89 113 2/23/2026
1.0.88 124 2/7/2026
1.0.87 131 2/7/2026
1.0.86 118 2/7/2026
1.0.85 125 2/7/2026
1.0.84 122 2/7/2026
1.0.83 126 2/7/2026
1.0.82 132 2/7/2026
1.0.81 347 12/18/2025
1.0.80 247 12/4/2025
1.0.79 245 12/3/2025
1.0.78 235 12/3/2025
1.0.77 353 8/6/2025
Loading failed

A Worfklow Solution usng configuration over code to connect to resources in Azure Cloud.