B - Advanced 3 - Importance of context

Purpose Purpose of this section is to introduce importance of context and the importance of the logic in which validation rules are ran. Also, as with any coding, we should take note that validatoin rule is only doing what it is told, which sometime

Description

Following steps are done here:

Making structured mandatory
Testing
Making remittance mandatory
Testing

Instructions

Before proceeding, we should make sure our project compiles as it is right now. This means that the previous invalid rule we have made in section 2 should be fixed.

1: Making structured mandatory

Lets use the automatical generation to make element structured to be mandatory.

At this point it's a good idea to first think what we assume might happen when we test this. It's a good idea to open the validation rule at this point but not to change anything.

2: Testing

Before testing, as a reminder, if testing by using validation service outside of Studio, project has to be deployed in addition to compliation to make changes visible.

We can test this by using the test file used in basic section. We should cover the following cases:

Remittance is not given
Remittance is given, Structured is not given
Remittance is given, Strucutred is given.

Below are relevant snippets of XML which can be used in the test file:

<Transaction>
    <Id>aaaaa</Id>
    <Amount>2</Amount>
    <Creditor>
      <Name>Creditor2</Name>
    </Creditor>
</Transaction>

<Transaction>
    <Id>aaaaa</Id>
    <Amount>2</Amount>
    <Creditor>
      <Name>Creditor2</Name>
    </Creditor>
    <Remittance></Remittance>
</Transaction>

<Transaction>
    <Id>aaaaa</Id>
    <Amount>2</Amount>
    <Creditor>
      <Name>Creditor2</Name>
    </Creditor>
    <Remittance><Structured></Structured></Remittance>
</Transaction>

We can now see that the only error will be given in the case when Remittance is given but not for the case when Remittance itself is missing.

3: Making remittance mandatory

Next, we should make remittance mandatory. We can use the automatical generation here as well.

4: Testing

In the testing phase, we can use the same file as before as well. Here we should now see that error will also be given in the case when Remittance is missing.

Conclusion

In the step 1, we only told the validation rule to make Structured mandatory and nothing else. Parent of structured, Remittance, is optional. Therefore, it was valid that Structured itself is missing as there is no requirement for it to be there.

When making validation rules, we have to know the exact case on how the logic of the validation rule should work. Is a certain element always mandatory? Is a certain element mandatory only when its parent is given?

Automatically generated validation rules always make one element mandatory and they never assume anything else. For this reason, in certain cases it is required to create multiple validation rules to make a whole XML tree to be mandatory if that is the case which is required.

It is also worth nothing that we do not have to make elements mandatory with OCL rule if they are already been made mandatory by schema. Theoretically it is possible to make these rules, but they would never trigger in the validation phase as a schema error would be given instead.