Rules in Transactions - More Knowledge

Transcription

1 Rules in Transactions - More Knowledge In a previous video we saw that the controls requested by users, or those we have to validate in transactions, are defined in the RULES section. We have already explained some of the rules that GeneXus offers, and now we will be showing some additional examples. If we take our application for a travel agency, in this example we will suppose that all customers accumulate miles as they travel on different tours. Let s note the specific structure of the Customer transaction: We can see that each customer may go on different tours. Now let s observe this attribute, CustomerTripMiles. It allows the entry of the miles awarded here in the second level of the transaction, for each tour made by each customer. Another design example, if the reality to reflect were this, would be to define that each tour has an associated number of miles to be awarded. So: TripMiles In the second level of the Customer transaction, that is: for each tour made by each customer, we could infer, have available this value of the TripMiles attribute through the TripId attribute, Page1

2 TripMiles just like we infer the value of TripDate and of the other attributes in the Trip transaction. But in this example we defined the miles received, by customer and tour, for the case they received different amounts of miles depending on the personal case: Also, each customer has a total of miles accumulated. Let s introduce the Add rule. In the Customer transaction we declare the following rule: Add(CustomerTripMiles, CustomerTotalMiles); What will be the behavior of this rule? The Add rule includes the following behavior: Page2

3 When a new tour is entered for the customer, the amount CustomerTripMiles is added to CustomerTotalMiles. If one of the customer s tours is deleted then the value of CustomerTripMiles is automatically subtracted from CustomerTotalMiles. And if the value of CustomerTripMiles is modified in relation with one of the customer s tours, the previous value of CustomerTripMiles is automatically subtracted from CustomerTotalMiles, and the new value of CustomerTripMiles is added, that is: the difference is adjusted. In sum: the add rule does exactly that, add. IT ADDS the first value to the second one when the user inserts... and solves the other transactions depending on whether something is being deleted or changed. Since this Add rule we defined has at least one attribute of the second level, then GeneXus understands that it is associated with the second level... meaning that this rule will be executed every time that the user inserts or deletes a line or every time that the user modified the CustomerTripMiles value in any line. GeneXus also provides the Subtract rule, whose behavior is totally similar to that of the Add rule, except that in this case, as its name indicates, it subtracts when the user inserts and does the other operations as the case may be. Let s analyze this rule then: Subtract(CustomerTripMiles, CustomerTotalMiles); When a new tour is inserted for the customer, the CustomerTripMiles value is subtracted from CustomerTotalMiles. If one of the customer s tours is deleted, then the CustomerTripMiles value is added to CustomerTotalMiles. And when the CustomerTripMiles value associated with one of the customer s tours is modified, the difference is calculated. Page3

4 We will now see a practical example of a particular aspect we must bear in mind when defining controls that combine the Subtract or Add tool with the Error rule. Let s analyze the Prize transaction that enables us to define awards given in exchange of miles redeemed. Customers are required to have a specific number of miles or more in order to be granted a particular award. So, when the user executes this transaction and tries to assign a customer to an award, it must be previously validated if the customer actually has sufficient miles. If the miles are enough and the award is granted, that number of miles has to be subtracted for that customer, or otherwise, if the miles accumulated are not enough, then the corresponding error must be announced. Let s now see the rules declared in this Prize transaction for solving this requirement: Subtract(PrizeMiles, CustomerTotalMiles); Error( The customer does not have enough miles ) if CustomerTotalMiles < 0; The Subtract rule, as we have explained will subtract the miles associated with the award from the customer s total miles when we insert the record of the award. On its own, the error rule deploys an error indicating that the customer does not have enough miles when the customer s total miles have a negative value. And why did we solve it this way? Because in this case both rules involve the CustomerTotalMiles attribute, where one of them updates it and the other rule evaluates its value. So, GeneXus determines that it must first execute the subtraction and then evaluate what happened with the value of CustomerTotalMiles. Since the subtraction is performed first, if the customer s accumulated miles are less than the amount required for the award, then the CustomerTotalMiles attribute will have a negative Page4

5 value and consequently the error rule must evaluate whether CustomerTotalMiles is less than zero or not. In such case, the Error rule is triggered, with the text that announces the error and the Subtract rule is undone, meaning that its execution is reversed, as if nothing had been done, and the customer s total miles remain unchanged. Otherwise, if after executing the Subtract the value of CustomerTotalMiles continues to have a positive value, then the Error rule is not triggered and the Subtract remains as it was done. We should remember that when the record corresponding to an award is deleted, the Subtract rules acts by adding. So, it will add the number of miles corresponding to the award to the customer s total miles. To see this in runtime, let s press F5 We select Work With Customers. We can see the customers registered and for each of them the number of miles accumulated. Note that, for example, Susan Parker has a total of 650 miles. Let s grant Susan Parker an award that is worth one hundred miles. We then go to the Prize transaction and record the new award. We select today s date, the description of the award that will be a dinner, the number of miles required; we select the customer, and when we infer the data we see that the corresponding miles have already been subtracted. We confirm the award and verify the result by going back to Work With Customers Now let s suppose that, for some reason, this award that was granted will be cancelled. From what we have seen about the behavior of the Subtract rule, if this award is cancelled, then the one hundred miles that were subtracted from the customer will be credited again. Let s then select the award and cancel it by pressing Delete. We return to Work With Customers, and can verify that the one hundred miles were actually added again. Let s now try to grant to Susan Parker a new award that is worth one thousand miles. Since this customer does not have sufficient miles, then the error message must be issued. We grant a dinner award again, then indicate the one thousand miles, and select customer Susan Parker. Since in fact this customer does not have enough miles, the error message is issued. Page5

6 And to end, and considering that in this case we cannot use the autonumber property with value Yes because this property only numbers simple primary keys, we will see a rule that offers the correlative automatic numbering of line identifiers, that is, the second level in a transaction. This rule we present is called Serial, for which we will see its use in the Country transactions we have defined in our knowledge base. We want CityId to automatically receive a number every time that the user defines a new line with a city, so it is not necessary to type it manually. Let s then declare the following rule: The first parameter must be the attribute to be numbered automatically. The second parameter must be an attribute that will necessarily have to be declared in the first level of the transaction and will be responsible for storing the last line number assigned so far. Let s then define it in the structure of the transaction, otherwise, it will not be possible to save this declaration. We go back to the sector of rules where we must explain that in the last parameter we should indicate the increase, that is, the numbering frequency we want. It should be mentioned that we can remove this attribute, CountryLastCityId, from the form if we do not wish to have it visible. However, it is a requirement of the Serial rule anyway. To see this in runtime we press F5 Serial(CityId,CountryLastCityId,1); We go into the Country transaction and enter Uruguay, with two cities We can see that the lines were numbered automatically, and the last value assigned is saved in the first level. Page6