Within applications developped with the Software Factory, there are several area's where data or a formula needs to be checked.
Imagine a task that will confirm an order.
Usually, you want to check the current status of the order, so that for example, current orders cannot be confirmed twice.
Also, you want to help the user, have the right task buttons available, so you apply the same logic to hide the task button, based on current status.
Unfortunately, these checks need to be put into two seperate control procedures, once for the task, once for the context procedure.
In the worst case, the developer decides to write these checks twice.
If he is a bit smarter he writes a specific function in order to test this case and handle the situation accordingly.
This would be, for now, also the advice I'd give to people; write a function to test and use this function in both task and context procedure.
Bad thing about this approach, is that a developer can forget to do one or the other.
I think the Software Factory can enforce these rules, on both context and task procedure. (Could also work for reports)
Setup would be quitte easy.
1. Define the rule (i.e. Order needs to be open when confirming)
2. Define input parameters (i.e. sales_order_id)
3. Link rule to tasks (The given rule applies to the linked task)
4. Link message to tasks (This message needs to be sent to the client when failing the check)
When this has been set-up, it would lead to automatically generated SQL code in both Task and Context procedure.
Task example:
if dbo.test_order_open_when_confirming(@sales_order_id) = 0
begin
exec tsf_send_message order_not_open, null, 1;
end;
Context procedure example
if dbo.test_order_open_when_confirming(@sales_order_id) = 0
begin
set @task_confirm_order_type = 1;
end;
Please feel free to critisise or elaborate on this idea. I'm curious to what we can come up with!
Open
Check procedures - Control procedure has been taken
Modeling conditions or constraints would certainly be a nice addition, for tasks and reports as well as for data manipulation.
In the example you quote, however, you might actually want to call the context procedure from the task to check all conditions. Unfortunately, this is not possible because context procedures are linked to tables, not to tasks, reports and details.
In the future we would very much like to do this differently (properly), but it has quite a bit of impact on existing context procedures. Which is also the reason that for Indicium we are working on a mechanism to perform tasks and reports from within the context of a table, to be able to enforce context procedure logic.
In the example you quote, however, you might actually want to call the context procedure from the task to check all conditions. Unfortunately, this is not possible because context procedures are linked to tables, not to tasks, reports and details.
In the future we would very much like to do this differently (properly), but it has quite a bit of impact on existing context procedures. Which is also the reason that for Indicium we are working on a mechanism to perform tasks and reports from within the context of a table, to be able to enforce context procedure logic.
+5Jasper wrote:
Which is also the reason that for Indicium we are working on a mechanism to perform tasks and reports from within the context of a table, to be able to enforce context procedure logic.
Wouldn't that lead to a false sense of security? There is nothing stoping anyone from still calling the task procedure directly (from another procedure or trigger). This would then execute this task without the checks applied by the context logic.
What we want to achieve with the method described is that business logic is always enforced when accessing the application via the OData API.
The decision whether or not to invoke a procedure or other logic from within code should be the responsibility of the developer. But I agree that modelling constraints would still be helpful here, and in many other scenarios. The business rules modeler that is currently being developed can also play an important role here for the more complex conditions.
Let's open your idea for voting and suggestions from other developers!
The decision whether or not to invoke a procedure or other logic from within code should be the responsibility of the developer. But I agree that modelling constraints would still be helpful here, and in many other scenarios. The business rules modeler that is currently being developed can also play an important role here for the more complex conditions.
Let's open your idea for voting and suggestions from other developers!
- Apprentice
I agree with Roberts stand point on applying the same logic in context and task alike to enforce functional integrity independent of the way a task/procedure is called. In addition to allowing the same logic to be applied to the context and task there may be scenario's where you'll want to apply the same logic in the layout and default in case it's not obvious why a task is ‘disabled’ through context for example in cases that rerely happen in some businesses like when a customer has exceeded its credit limit which prohibits the user of the system to sell new items to this customer (e.g. execute task ‘add_sales_order_item’). By disabling this task it can be confusing for the user why the task can’t be executed. The user might spend unnecessary time figuring out why this is. I.m.o. instead its more user friendly to show a message to the user - before entering the task parameters and executing it - explaining that the customer has exceeded the credit limit. Obviously this has to be done through the default and the confirm button has then to be disabled using the layout.
What do you guys think?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.