DI and Business Rules

[bashinamwila]

We have multi tenant application in which tenants are able to define their on business rules using wizards.However we require the tenant id to retrieve the appropriate business rules for a specific tenant for a particular BO using the approach suggested by @rockfordlhotka in issue #847 in the old forum.The tenant object is injected in data portal's create or fetch,however these methods are run after the AddBusinessRule override has run on first initialization and the tenant is null is this instance.We tried to use an anti-pattern of using the GetService method of the ServiceProvider. However the Csla.ApplicationContext.DefaultServiceProvider is write only and Csla .NET does not support constructor injection.

How do we get the tenant id in this instance?

[rockfordlhotka]

Normally you'd put the tenant id as a claim in the ClaimsIdentity for the user, because each user might sign in under a different tenant.

Or put the RuleSet name in the ClaimsIdentity - kind of the same thing, as you want the rules engine to use the correct rule set for the user's tenant.

[rockfordlhotka]

@pszittyay it depends on your runtime.

If you are in a smart client runtime (winforms/wpf/blazor wasm/etc) you set the current rule set any time the user logs in, and it remains in place for the lifetime of the app.

If you are an aspnet runtime, you need to set the current rule set for each inbound request, because the server is stateless. So once the user's identity is established for the current inbound request, you set the current rule set, and it remains in place for the lifetime of the current request.

If you are a server-side Blazor runtime, it should be the same as a smart client runtime, because the current rule set is maintained in the ApplicationContext instance for your current scope - and so should remain in place for the lifetime of the server-side Blazor session.

[pszittyay]

@rockfordlhotka thanks for the response
We are currently using a winform/blazor runtime. The problem is that we have a set of rulesets that are common to all tenants and a few that depend on the tenant. I read the books and threads but did not found any example of this scenario.
Maybe i should raise this question in a separate thread

[Chicagoan2016]

@pszittyay
The 'rulesets' that are common to all tenants will become your default ruleset.
The 'dependent' rulesets need to be set based on tenant id.
You could read about it on page 87 and onwards in Creating Business objects book (Using Csla 4.0).

[pszittyay]

Hi, we have migrated to CSLA 7 from 5 so now we can use ClaimsIdentity and Claim for the RuleSet depending on the Tenant
My question is whats the Claim name i should use so that the rules are only excecuted if the Tenant is equal to the Tenant Claim value
This is my login method

            baseidentity.AddClaim(new Claim(ClaimTypes.Name, identity.Principal.Identity.Name));
            baseidentity.AddClaim(new Claim("UserId", identity.Principal.Identity.Name));
            baseidentity.AddClaim(new Claim("FullName", identity.Principal.Identity.Name));
           --how to set the RuleSetName 
            baseidentity.AddClaim(new Claim("XXXX", ConstantesDegas.SiglaDistco)); 

and in my BO

            BusinessRules.AddRule(new Required(PrioridadProperty, "La Prioridad debe tener un valor"));
            BusinessRules.AddRule(new Required(IdPuntoProperty, "El Punto debe tener un valor"),ConstantesDegas.SiglaDistco);
            BusinessRules.AddRule(new Required(IdPuntoProperty, "El Punto debe tener un valor"),ConstantesDegas.SiglaDistco);
            BusinessRules.AddRule(new Required(TipoProperty, "El Tipo debe tener un valor"));

[rockfordlhotka]

As we discussed in Discord, the way the ruleset feature works is that only one ruleset is active at a time.

The default ruleset is just another ruleset, so it is active if no other ruleset is active, but it is not active if another ruleset is active.

There is no automatic mechanism for setting the active ruleset. You need your code to set the active ruleset for the current user.

It is an interesting idea to think about: automatically setting the current ruleset based on a claim from the current user. The ruleset feature predates the ClaimsPrincipal, at or least its widespread use, and so when ruleset was created it wasn't tied to any specific user value. Now, with the widespread use of ClaimsPrincipal, it might be realistic to tie them together.