Hi@HERCH

Thanks for getting in touch.

Yes, yes, yes! Good news.
Precisely what it is designed for, running in different environments, with different technology stacks, be them Local, OnPrem or Cloud.

You said,

We understand that opting for an OnPremise approach might result in losing many features typically available in a cloud environment

I'm guessing you might mean that in Desktop<->OnPrem systems you don't have the common cloud services, we might be used to seeing, especially the messaging components?

In terms of adapting to different environments, that is trivial really, You simply swap out and plugin the technology adapters that you have in your environment - no other code changes.
(All interfaces for all external services, including databases, etc. have been abstracted and well-defined, as you would expect in a Clean/Onion/Hexagonal architecture..)

Essentially the architecture as it is, depends on the following list of infrastructure services to operate correctly as designed, albeit, they are all completely technology agnostic:

For any runtime environment, be it OnPrem, Cloud, Local whatever, you would need to have something for all these persistence services.
(You can see this working on your local machine, after cloning and compiling, with no external infrastructure installed. It is all handled by local adapters to your local disk - only for local development, of course!)

• AnIDataStore. in your case this would be SQLServer (existingAzureSqlServerStore adapter will work perfectly fine in Cloud or OnPrem - it really just usesSqlClient).

• AnIQueueStore. reliable single consumer JSON messages. You need this available to code from your server. It could be any OnPrem technology you want. e.g. RabbitMq, Redis Queues, MSMQ, etc, or you can simply connect to one of these services online, or to your own instance in any cloud provider Azure/AWS, etc.

• AnIMessageBusStore reliable FIFO topics - multi-consumer JSON messages. You need this available to code from your server. Same as queues above.

• AnIBlobStore to store binary files (pictures etc.). You need this available to code from your server. It could be any OnPrem technology you want. e.g. FileSystem, Relational Database, NoSql database, etc, or you can simply connect to an online services like DropBox, OneDrive, or to your own instance of AzureStorageAccount or AWS S3 buckets, etc.

• AnIEventStore to store the events from event sourced aggregates. You can choose to have event-sourced aggregates or not (we recommend you do). If you do, you need a robust EventStore for those events. You can do that in any Sql or NoSql database technology (it wont require any schema), the includedAzureSqlServerStore is built to do this for you also.

If memory serves me well, I think everything else that is built in can either be stubbed out, or you can redirect to external 3rd party services, like for Email, Metrics, etc.

Hey@HERCH

Take a look at the HttpClient scripts intools/httpclient folder, specifically:CreateUser

OR
have a look at the integration test forPasswordCredentialsApiSpec.cs

You will notice that with a user registration (using credentials) that its a multi step process.
Register -> Email -> Confirm -> Authenticate -> Access

Whereas registration with SSO is slightly different.
Authenticate -> Access

Also, if you running locally (on your local machine) we DO NOT have the AzureServiceBus (or equivalent) running, so there is not guaranteed delivery of the events from topics to subscribers.
So, sometimes, we have to trigger that process manually - to disseminate thedomain_events.
Hence the need to call the endpoint/domain_events/drain manually in both integration tests and in local debugging.

We actually do have a background service that is running in theTestingStubApiHost that does try to process thedomain-events on the local message bus, but it is a polled thing, not real-time.

To your second point.
Your problem with machine APIKeys is probably related to above point. In other words, if the events have not propagated properly, the data is probably not in place to allow you to create machine keys yet, That is a guess, not knowing what issues you see, specifically

To your third topic.
Yeah a RabbitMQ QueueStore of would be a great contribution. Yes please.
Have you added the necessaryIntegration.Persistence tests for it - like the others, to make sure it works properly?
If so then we can probably run it in a Docker container (like the other server components) for testing.
Yes, I would be keen to have that as an adapter in the codebase.

Hello again@jezzsantos,

I am back with some updates. I have now migrated the Azure infrastructure, specifically regarding ServiceBusStore, QueueStore, and BlobStore. I have practically adapted the IDataStore and IEventStore implementations without changes for our on-premises version.

Additionally, I have completed the implementation of RabbitMQ and created the integration tests, adding a new emulator for RabbitMQ and replicating the Azure tests. So far, everything is working fine.

However, I encountered a small issue, which I describe below:

When practically cloning the file and renaming it (from AzureSqlServerStore.IEventStore.cs to SqlServerStore.IEventStore.cs), in lines 54-55:

Common.Resources.EventStore_ConcurrencyVerificationFailed_StreamAlreadyUpdated.Format( streamName, version));

I am unable to access the resource Common.Resources.EventStore_ConcurrencyVerificationFailed_StreamAlreadyUpdated, as Resources is not accessible.

Could you please guide me regarding this point?

Thank you in advance.

Hey@HERCH

We very recently updated the concurrency handling for the store, and moved this particular resource in that commit:36b7b77.
I would advise upgrading your code with the changes in SaaStack, as of: Feb 10th.

I am not sure if you are on a fork, or on a clone, the process to update will be different.
For example,
we have a clone, and simply use git patches to stay on top of updates. If you are on forks, you can either use git patches, or you can use standard git tools to fast forward latest updates.

Hi@jezzsantos,

I’ve created two Pull Requests (PRs) for the integration of the On-Premises version:

1️⃣ First PR: Includes the RabbitMQ emulator setup, persistence implementation, and Service Bus & Queue management.
2️⃣ Second PR: Adds the ONPREMISES global variable and makes the necessary adjustments in Infrastructure.Web.Hosting.Common.Extensions to enable execution from ApiHost1.

🔍 Request for Guidance
Now, I need some guidance on how to deploy this in a real (production) environment. I’m considering that the best approach is to develop a WorkerService, and I already have an initial implementation. However, at this stage, I feel a bit lost:

📌 Main Question:

My test worker is currently using localhost:5656, but in my case, I have only implemented the worker with the consumer.
I'm unsure about the best way to execute the workflow:
📌 Option 1: Use an API (5656) to manage interactions.
📌 Option 2: Allow handlers to directly interact with the workflow.
Given your expertise, I would greatly appreciate your guidance on this matter. I’ve been working on microservices development for several years, and this project has been a fantastic learning opportunity for me.

I’ll share my progress on the workers so we can stay aligned and discuss the best approach.

📌 Current Code - EmailMessageHandler
Below is the code I currently have working for handling email messages in the system:

using Application.Persistence.Shared.ReadModels;using Infrastructure.Web.Api.Interfaces.Clients;using Infrastructure.Workers.Api;using Newtonsoft.Json;namespace OnPremisesWorkerService.Workers.MessageHandlers;public class EmailMessageHandler : IMessageHandler{    private readonly ILogger<EmailMessageHandler> _logger;    private readonly IServiceClient _serviceClient;    private readonly IQueueMonitoringApiRelayWorker<EmailMessage> _emailMessage;    public EmailMessageHandler(        ILogger<EmailMessageHandler> logger,        IServiceClient serviceClient,        IConfiguration configuration,        IQueueMonitoringApiRelayWorker<EmailMessage> sendEmail        )    {        _logger = logger;        _serviceClient = serviceClient;        _emailMessage = sendEmail;    }    public bool CanHandle(string routingKey) => routingKey == "emails";    public async Task HandleAsync(string message, CancellationToken cancellationToken)    {        var emailMessage = JsonConvert.DeserializeObject<EmailMessage>(message);        if (emailMessage == null)        {            _logger.LogError("Invalid email message");            return;        }        try        {            await _emailMessage.RelayMessageOrThrowAsync(emailMessage, cancellationToken);            _logger.LogInformation(                "Email sent : {To} - ID: {Id}",                emailMessage.Html.ToEmailAddress, emailMessage.MessageId);            await Task.CompletedTask;        }        catch (Exception ex)        {            _logger.LogError(ex, $"Error sending email: {ex.Message}");            throw;        }    }}

Thanks in advance for your support! Looking forward to your insights.

Best regards,

In the first PR, you mentioned that the implementation of the new assembly didn’t make sense. However, after reviewing the second PR, you reconsidered and stated that the creation of an additional platform called HOSTEDONPREMISES now made sense.

What I did was clone the pre-existing Azure project and adjust the AzureServiceBusStore and AzureStorageAccountQueueStore files for implementation using RabbitMQ. Additionally, I modified AzureStorageAccountBlobStore so that storage is handled within a database (DB).

After deleting the two previous PRs, new doubts arose due to a comment where you suggested creating a dedicated adapter for RabbitMQ (which I have already implemented). Now, the question is how to handle SQL Server:

Should I reuse the Azure implementation (which I don't think is ideal)?
Or would it be better to create a dedicated SQL Server assembly that can be shared across both Azure and On-Premises?
From my perspective, it seems better to revert to the previous version, continue working with the HOSTEDONPREMISES platform, and create two new assemblies: RabbitMQ and SQL Server, which would be shared between Azure and On-Premises.