Source: GitHub

This article talks about an interesting difference between passing null and no value for a column in the payload of an ADF BC REST end-point. Now this might seem a bit obvious in the end, but nonetheless, it can be confusing at times.

To demonstrate this problem, I have the following use-case: Set a default value for employee "Salary" during insert or update!

Now your GUI might have some required validation set on this field, and it does not allow the end-user to save the form without a non-zero salary. That is all good. But your QA might have an automation running to check the REST APIs with their own payload. And this is something which needs to be in sync with the UI logic.

To get started, I have my Employee entity object with a default value of 5500 for Salary field.

Case # 1: Payload does not contain Salary attribute

When I submit this payload, I get back an Employee object with the default Salary of 5500, as declaratively set up on the entity object.

Case # 2: Payload contains NULL or EMPTY Salary attribute

Now when I submit this payload, I get back an Employee with null Salary.

This is quite expected, isn't it? Salary accepts null values, and we are passing null explicitly in the payload, so they all work out well! It's not a crime to pass NULL!

But what if we still want the default value to set be set, irrespective of whether Salary is null or Salary is excluded from payload?

In that case, we would need to explicitly check for null and set a value in the overridden prepareForDML method. To distinguish between the two scenarios, I am setting a different value 4500 (not 5500) in the method.

Now when I submit the same payload (with null Salary), I do get back an Employee with 4500 salary.

Now again, this might seem obvious, but it can add some value to your application, depending on your use case.

UPDATE: There is another interesting scenario which has been missed above. I have covered that in a subsequent article: Defaulting with CREATE method.