11 articles about Business rules, in reading order.
Business rules
Parsware has several places to put a rule. Form rules make a form respond as you type. Plugin steps decide what may be saved, however it's saved. Custom APIs answer other systems, scheduled jobs run on a clock, and processes carry work between people. This guide says which one to reach for, with a real example of each.
Business rules
A form rule runs in the browser and changes the form as you type. In the Expense Approval sample, typing "rejected" into Status shows a Rejection reason and makes it required, and approving the claim hides it again and locks the amount. Here is the form, the three rules behind it, and the one script they share.
Business rules
A claim over 1,000 needs an approval note. The form can show that as you type, but only a plugin step makes it true, because it runs on the server whatever saved the claim. We imported a spreadsheet of claims past the form and watched two rows refused with the step's message, then looked at how one script holds the limit for both sides.
Business rules
A server validation rule is a plugin step that refuses a save and says why. We added one from scratch, "a claim over 10,000 needs a purchase order", then watched the editor catch a misspelt function and the form show the step's message when we saved a claim that broke it.
Business rules
A plugin step is registered against a table, a write, a stage and an order, and the stage decides the most. We put a second step behind the order-stock sample's own, watched a refusal before the write undo the stock the first step had taken, then moved the same refusal after the write and watched the order line stay.
Business rules
The answer to "is there enough stock?" isn't on the order line. It's on the product. We saved three order lines against a product with 10 in stock and watched a plugin step read the product, take the stock and log the movement, or refuse the line, then read the script that does it.
Business rules
Not every server rule refuses. This one approves. A claim of 50 or less is marked approved as it's saved, by a plugin step that sets a value on the record before it's written. We saved a taxi fare and a hotel bill, watched only one come back approved, then watched the sample's own lock stop the approved one being edited up.
Business rules
A plugin step that runs after the response has nobody to tell when it fails. So it tries five times, and then it waits on a list. We made one fail for a real reason, read the failure, fixed the setting it needed, and pressed Retry.
Business rules
A loop that never ends is a typo away, and on the server it would hold a save open forever. So every script runs on a budget. We wrote two broken plugin steps, a loop counting the wrong way and a function with no way out, and read what the platform says when it stops them.
Business rules
The same solution in two environments should call two different payment services, a sandbox in one and the real thing in the other, without anybody editing a script. That's what an environment variable is for. We installed one solution in two environments, gave each its own value, and saved the same order in both.
Business rules
A security role says what somebody may do with a table. A data policy says which records that reaches, and when a save is refused. We imported a sample with one of each kind, gave its role to two regional managers, and watched the same grant show each of them a different list and refuse one of them an approval.
