Cast of value assignments in Studio

Hopp operates with an internal type system to ensure that migrated field values are valid. Everywhere in Studio where you create a field, or a parameter, you also give it a data type and specify if a null value is acceptable.

For instance, when defining an Interface Field on a Business Object in the Target Map:

In the screenshot above, the Interface Field IbanNumber is of data type Char, it may be null but it may not be longer that 30 characters.

Studio will not allow you to make incompatible assignments of incompatible data types. For instance, if you have a field of data type Date, Studio will only let you assign values of type Date to that field.

In the screenshot above, Studio will only let you assign one of the Date interface fields to the Target Field StatusStartDate. The other interface fields on the CardStatus Business Object are of data type Num and Char, so Studio will not let you pick them because they are not compatible with the Date type of the field you are assigning to.

But if the data types are compatible, Studio is somewhat lenient when it comes to assignment warnings. Like for instance assigned a char value that may be 50 long to a rule parameter that is only 30 long. In most places, Studio will let you do that without complaining.

Strict type check

But there are 2 specific places where Studio gets very strict and will complain loudly if there is any problem with the data type of a value being assigned. 

That is when you 

• Assign values to Target Fields in the Target Map
• Assign values to Interface Fields in the Source Map

This is because in these 2 cases, the values must adhere to the contract between either the Source Map and the Target Map as it is expressed in the Target Interface imported into the Source Map - or the contract between Target Map and the Target System as it is expressed in the imported Target Metadata in the Target Map.

In these 2 cases, Studio will flag if the assignment may result in a value that is not 100% compatible, for example a Char that is too long or a Date that is null.

An example

In the first screen shot above, an Account may have an IbanNumber - but it does not have to. That is why the IbanNumber Interface Field is marked as nullable.

If the IbanNumber is not null, the Target Map delivers a Target Object with the Iban number:

The Tgt.Acc_Id_Relation [IbanNumber] Target Object is guarded by a condition rule, so it will only be created if the IbanNumber Interface Field is not null:

To sum up: 

• If IbanNumber is null
  • Tgt.Acc_Id_Relation [IbanNumber] is not created
• If IbanNumber has a value
  • Tgt.Acc_Id_Relation [IbanNumber] is created

The thing is, according to the Target Metadata, the corresponding value in the Target Object may not be null (if it was nullable, it would have a question mark after the data type: Char(30)?):

Since you have the Condition Rule in place, you know for sure that if the Target Object is created, the IbanNumber is definitely going have a value.

But Studio does not know that, so it wants your reassurance that this is ok. Is does that by asking you to cast the nullable value of the Interface Field to the not-nullable value of the Target Field:

If you do not do the cast (check the Cast checkbox), the Studio validation will demand it with a validation error 0042 signaling an assignment error: 

Once the cast checkbox is checked, the validation error will go away. 

As a side note, another way to clear the assignment validation error is to change the type of the value being assigned. But this may not always be possible. Specifically in the example above, the IbanNumber interface field is nullable for a very good reason and it is not an option to make it not-nullable.

Rule return value

But in other cases, for instance when the assigned value is returned from a rule, it may be a more sound option to change the return value of the rule instead of casting the value.

In this context, it is worth noting that for a lookup rule, the default chosen to return if the lookup does not find a row is significant. If the default value to return is Null, then the return type of the lookup rule automatically becomes nullable. 

For lookup rules it is often beneficial to return a Literal default value instead of Null. For instance, if the the return column of a lookup rule is of data type Num and the default return value is Null, then the return type of lookup the rule is a nullable Num?. But if the Literal 0 was chosen as default return value instead of Null, the return type of the rule become a not-nullable Num.

Redundant cast

If on the other hand, new metadata were to be imported at a later stage and the Target Field suddenly became nullable, the cast is redundant. Studio will flag this with another validation error 0206: Cast is redundant and must be removed.

Runtime check

Finally, when the generated Target Engine is executing and gets to the point where the interface value for IbanNumber is assigned to the Target Field, it will validate the assignment. If the IbanNumber somehow is null, the Target Engine will emit a System Event and discard the Business Object.

However - and importantly - the Runtime check is skipped is the Business Object currently processing is discarded