How to Update a Field Only When It Is Empty in OFS

A common OFS requirement sounds simple: update a field, but only if the record does not already contain a value. Perhaps an external onboarding system supplies a reference, or a downstream process fills in a value that should never be overwritten later.

The risky implementation is to read the record outside T24, decide that the field is empty, and then send a second OFS request to update it. That creates a gap between the check and the write. Another process can fill the field during that gap.

The safer design is to send the intended value through OFS and enforce the empty-field rule inside the T24 transaction path.

Separate transport from control

OFS is the message interface. It carries the application, operation, user context, source, and data into T24. It does not, by itself, express every business policy that the receiving application should enforce.

“Only write this value when the current value is empty” is a business control. It needs access to the current record and must be evaluated as part of the update, using the validation or input mechanism supported by the application and release in that environment.

Why a read-then-write flow is weaker

An external integration may follow this sequence:

1. Read the current record.
2. Check whether the target field appears empty.
3. Build an OFS update using the value from step two.
4. Send the update later.

The check may have been correct when it ran and still be wrong when the update arrives. A retry, parallel consumer, user edit, or batch process can change the record between the two requests.

A pre-read is still useful for display, diagnostics, or deciding whether to ask a user for more information. It should not be the only protection for a rule that must survive concurrent updates.

The safer processing pattern

Keep the OFS message focused on the requested change, then make the receiving application perform the check before it writes:

on update request:
  read the current record
  if target field is not empty:
    return a clear business error
  validate the incoming value
  write the value through the normal transaction path
  return the normal success response

The exact hook, version configuration, and error-handling mechanism vary between implementations. The important property is that the check and the update are part of the same controlled processing path, rather than two unrelated calls made by the integration client.

If the field is already populated, reject the request unless the business contract explicitly says that the update should be ignored. An explicit error is usually safer than a success response that quietly left the requested value unchanged.

Define what “empty” means

“Empty” is not always one obvious database state. Agree the rule before writing the validation logic:

• Does an absent value count as empty?
• Does an empty string count as empty?
• Are spaces, placeholder values, or default codes treated as empty?
• For a multi-value field, must every value be empty or only the target value?
• Should a value from an earlier system be considered final?

These decisions belong in the business rule and test cases. If they are left implicit, two teams can both believe they implemented “only when empty” while applying different definitions.

Place the rule at the right layer

OFS sources can have hooks that transform incoming messages or perform work around processing. Their timing matters. A message transformation hook can normalise input, but a post-processing hook is too late to stop a value that has already been written.

Keep the empty-field decision in the application or version validation path that still has access to the current record before the update is committed. Use surrounding OFS hooks for channel-specific formatting, logging, or notifications rather than assuming they provide the final business control.

Use VALIDATE as a pre-flight check

Where the channel and implementation support it, send a changed message through OFS validation before using the processing path. This helps catch malformed data, missing mandatory fields, and ordinary application validation errors without committing the update.

Treat that result as pre-flight evidence, not as the final concurrency guarantee. The record can change between validation and processing. The empty-field rule must still be enforced when the real update is handled.

A useful support record keeps both responses: the validation result and the eventual processing result. That makes it easier to distinguish a rejected message from a race, a retry, or a later business change.

Test the rule before production

Test the business rule with a small matrix rather than only one happy path:

1. The field is absent and the request supplies a valid value.
2. The field is empty and the request supplies an invalid value.
3. The field already contains a value and the request tries to replace it.
4. The field contains a placeholder or default that needs an explicit policy.
5. Two updates arrive close together for the same record.
6. The client retries after a timeout without knowing whether the first request committed.

For the last two cases, check both the final record and the responses. A test that only proves “the first request worked” has not tested the risk that motivated the rule.

Practical checklist

• Keep the OFS request responsible for carrying intent and data.
• Enforce the empty-field condition inside the T24 update path.
• Define empty, placeholder, and multi-value behaviour explicitly.
• Return a clear business response when an existing value blocks the update.
• Use validation as pre-flight evidence, not as a substitute for final enforcement.
• Use a stable message reference and configured duplicate checks where available, while still enforcing the field rule.
• Record enough request and response context to investigate retries safely.

The goal is not to make the OFS message clever. It is to make the update rule deterministic, auditable, and safe when more than one process can touch the record.

Further reading

• What Is OFS in T24? — understand the message structure and processing modes.
• OFS Response Errors — diagnose failures by processing stage.
• Trace a Failed OFS Request — follow a request through TAFJ and JBoss logs.
• OFS Builder — construct generic OFS messages for controlled testing.