Yellow messages (business constraints) in practice

[stefjoosten]

Problem

A yellow message contains the violations of a business constraint (aka process rule) to all users with the ROLEs that maintain that business constraint. When an information system is being used by one or a few users, this is no problem. In reality, information systems serve many users simultaneously. In such cases we need a mechanism to get yellow messages only to the people who need them.

Use cases

1. In the Kruk.adl prototype, we integrate three small demos into one. Two of the demos each start with one of their business constraints being violated, so we'd like to see one yellow message bar in each demo. However, we get to see both yellow bars in each of these demos because they are combined in the same script.
2. In the Semantic Treehouse project of TNO, Ampersand is running in production with many different users. The authors have systematically avoided using business constraints, precisely for this reason. Instead, they have implemented an exec-engine rule that triggers a user to do whatever is needed.

Solution

@sjcjoosten, I understand you have an idea? Please describe it here by editing this comment, so the proposed solution appears in the first comment of this issue.

I suggest that @hanjoosten, @Michiel-s, @sjcjoosten, and @stefjoosten discuss this issue further.

[RieksJ]

Surprised to see this is a problem. I'm not in touch with the latest developments, but earlier, the yellow messages were violations of process rules, which means there is a role associated with each of them. If I remember correctly, the desired behaviour will appear when you use SIAM, which means your users need to get/register accounts and the roles they perform.

I would think, but am not sure, that the yellow messages test to see if sessionRoles (if that is the relation) exists, and if so it will only display the messages for which there is a role in the current session that is responsible for the associated rule violations.

[Michiel-s]

For the Semantic Treehouse project we indeed avoid process rules (that can be violated) for human users. This is because the rules are only MAINTAINED by a role. So every user who has that role sees the violations. But in most situations such business rules also need to be context/content aware. E.g. if Every project requires a description, such rule should not be maintained by all users that have the role Project leader, but only for the project leader of that particular project.

[RieksJ]

This can be done by adding a term to (the left side of) the violation expression that filters out the users for such roles that have dealing with the subject matter. For example, if there is an order, and a particular user assigned as the order manager, as in manager[Order*Account], then any rule regarding orders of the form r[Order*X] |- s can be rewritten as (I /\ V;_SESSION;sessionAccount;manager~);r |- s. Similar constructs can be made for other cases.

[Michiel-s]

Good that you mention this possibility, because I now realize that there is a wrong way of caching implemented. There is a conjunct cache implemented that stores violations in a database table. It allows to more quickly show process violations. However, new violations that are created for a given session, are also shown to other sessions with the same role.