SAP does not make this quite easy....there are TWO levels here...
1. rules at the SERVICE level: this is at the backend services "spot"...where you config ALL the SERVICES (not operations of service) you use. The rule(s) you create there will control if a service itself is executed(drilled into its operations) or skipped. If the rule evaluates as "true" it is executed. The field(s) you use in your rules can be ANY in your form scenario fields.....no limitation.
2. rules at the OPERATION level: once "inside" a service in configuration, we define which operations of the service we want. We can attach rules to these much the same as services. However, there is one BIG difference....any field(s) we use in a rule attached to the operation must have that field mapped to the operation.....this mean you can't just use "any" field to evaluate your rule....it MUST be mapped to the operation...which is fine if your field is part of the operation but there are times where you are checking something else you don't need directly in your operation....for example, if our operation had fields mapped like this....
FORM FIELD FIELD GROUP OPERATION OPERATION FIELD
i0006_street FG01 CHECK_ADDRESS stras
i0006_city FG01 CHECK_ADDRESS ort01
i0006_zip FG01 CHECK_ADDRESS pstlz
Then we could not have a rule like "if i0006_country = USA" because the field "country" is NOT part of the operation mapping.
To get around this, we make use of "flag" fields, map those to the operation to some "unused" field and mark them as "exclude from operation"...so they ARE mapped but not actually used.
Make sense? To "check" your rule, put breakpoints into your generic service code or in the framework code (you can find the loops where it checks rules) and debug.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.