Data Attribute Recommendation (DAR)

The problem it solves

In SAP we often face the same issue: too many fields, too many attributes, too much manual work. Most values follow patterns — but users still re-type them. SAP's Data Attribute Recommendation (DAR) learns those patterns from your history and suggests values while you create new records.

• Example: creating a Business Partner — suggest Account Group, Region, Payment Terms.
• Example: creating a Sales Order — suggest Incoterms, Payment Method, Delivery Priority.

What DAR is (in plain words)

DAR is a machine-learning service trained on your historical master or transactional data. During entry, it predicts likely attribute values so users confirm instead of typing.

1. Collect: export representative historical data.
2. Train: learn mappings like “if X and Y → usually Z”.
3. Predict: during create/change, propose values.
4. Feedback loop: confirmations/corrections improve accuracy.

When to use DAR (decision criteria)

Limits to keep in mind

• Garbage in → garbage out: poor history = poor predictions.
• Cost/runtime: typically runs in BTP; introduces dependency and cost.
• Opacity: mostly a black box; not every prediction is explainable.

Integration patterns (SAP)

Common hooks: Fiori create flows, RAP behaviors, BAdIs in MDG or SD/MM master data, or CPI/iFlow calls.

ABAP call to a prediction API (synchronous)

DATA: lo_http TYPE REF TO if_http_client,
      lv_url TYPE string VALUE 'https://ml.example.com/predict/dar',
      ls_req TYPE string,
      ls_res TYPE string.

" Build minimal JSON with known inputs
ls_req = |{{ "bpCountry": "{ bp-country }", "industry": "{ ind }", "salesOrg": "{ vkorg }" }}|.

cl_http_client=>create_by_url(
  EXPORTING url = lv_url
  IMPORTING client = lo_http ).

lo_http->request->set_method( if_http_request=>co_request_method_post ).
lo_http->request->set_header_field( name = 'Content-Type' value = 'application/json' ).
lo_http->request->set_cdata( ls_req ).

lo_http->send( ).
lo_http->receive( ).

ls_res = lo_http->response->get_cdata( ).
" Parse JSON -> fill proposal structure, then show to user or prefill fields.

RAP behavior: prefill before save

CLASS lhc_ZR_BusinessPartner DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.
    METHODS determine_defaults FOR DETERMINE ON MODIFY
      IMPORTING keys FOR BusinessPartner~determineDefaults.
ENDCLASS.

CLASS lhc_ZR_BusinessPartner IMPLEMENTATION.
  METHOD determine_defaults.
    " For each BP being created, call inference and set transient fields
    LOOP AT keys ASSIGNING FIELD-SYMBOL(<k>).
      " ... call HTTP as above, parse JSON
      " map: paymentTerms, accountGroup, region, ...
      " set in result NEW BusinessPartner %tky = <k>-%tky paymentTerms = lv_terms ...
    ENDLOOP.
  ENDMETHOD.
ENDCLASS.

DIY alternative (no vendor lock-in)

You can achieve DAR-like behavior on your own stack (ROSA mindset):

• Export history → train classifier (scikit-learn, XGBoost, LightGBM, TensorFlow).
• Serve model via REST (FastAPI) behind mTLS; log every request/response.
• Call from RAP/BAdI synchronously, or use request → outbox event → infer → callback asynchronously.
• Add retries, idempotency keys, and DLQ for resilience.

Async option (EDA)

asyncapi: 2.6.0
info: { title: DAR alt, version: "1.0.0" }
channels:
  attribute/predict:
    publish:
      message:
        name: AttributePredictionRequested
        payload:
          type: object
          properties:
            entity: { type: string, enum: [BusinessPartner, SalesOrder] }
            inputs: { type: object }
  attribute/predicted:
    subscribe:
      message:
        name: AttributePredicted
        payload:
          type: object
          properties:
            entity: { type: string }
            proposals: { type: object }

UX pattern — how it feels in Fiori

• Fields show ghost placeholder with suggested value.
• User confirms with one click or edits value → feedback is stored.
• Confidence badge (e.g., 92%) helps decide when to trust.

Security & operations checklist

• mTLS between S/4 and inference API; rotate keys.
• PII minimization: send only necessary fields; mask IDs where possible.
• Audit log: who saw which suggestion, and what was accepted.
• Shadow mode first: log predictions without applying, verify accuracy offline.
• Blue/green for models; version every schema.

FAQ