What is the logic of ERP systems based on?

Question

ERP

Good time to all, such a question has come up, to everyone who has heard about the planned systems of the so-called ERP and CRM.
All these systems are based on abstractions, for example, NSI and Registries
. The question is how the logic of the application works if all the business logic is tied to the NSI abstraction
. Well, let's say we have a user type directory and a directory of his access rights .
these directories, how to rely
on the processing of input data, and actually how to rely on the verification of these records after processing?
Let's say - checking the type of user and the rights that are allowed to the user for some action are possible as follows - checking the user field for rights - extracting rights from the directory by the given identifier , then skipping or denying the action
But as everyone knows, directories are dynamic things, they can be changed or removed altogether, what then happens in the code, redo everything again, or are there any more universal methods?
How is the life of a business logic that relies on unstable data for which it was created?

Answer 1

How is the life of a business logic that relies on unstable data for which it was created?

In short: a dynamic storage structure is created with pre-known role relationships to each other based on any database management system with data integrity control inside this storage.
There is such a thing as "data integrity".
When adding an entry to one of the roles, they are automatically asked to match (or create) all the necessary fields to ensure data integrity.
The same is true when trying to remove any linking entity from the record chain.

Answer 2

In my opinion, you have a confusion of two loosely coupled features of the system.
On the one hand, you are talking about NSI (as far as I understand the Reference Information), and on the other hand, about the so-called RBAC (role based access control).
It can be decomposed as follows:
1) There are users who, on the one hand, are a directory, and on the other hand, the subject of user identification in the system
2) There is a role that consists of a set of possible actions in the system.
3) A user can have several roles and user rights are calculated based on the totality of the maximum available rights.
Moreover, the possible actions of the system are not a fully dynamic directory, i.e. there are things that are not removed from there.
Let me give you an example: we have a certain ERP in which there are 300 employees and 3 roles - "guest" (in fact, it may not exist in the system), "employee", "administrator".
If we bind all 300 users to the "Employee" role, and then try to delete it, then there may be several options for solving this situation (different systems use different methods)
In terms of deleting a role:
- The role is not deleted as long as there is at least one an employee with such a role
- The role is marked deleted and it is no longer taken into account in the set of rights, but is displayed in the system
- The role is deleted only if the user has marked which role to add existing users to
- The role is simply deleted, leaving the system in a "broken integrity" state.
As for the question about directories, in the general sense of the word, this means mainly user information of a reference (suddenly!) Character. Those. this information does not affect the technical aspect of the system, but is directly tied to the business logic of the system (everything can be disputed, of course).
For example, a guide can be:
- Type of ownership (State, Municipal, Private, etc.)
- Legal form (Partnership, Company, Joint Stock Company, etc.)
- Sphere of interests (IT, Agriculture, etc.) n.)
That is, any information presented in the form of a list.
PS In a particular case, both users and roles are also directories.