🤖 I’m Not an ABAPer, But I Shipped an SAP OData Service with AI
Disclaimer & Anonymization
Examples are anonymized and simplified. Replace placeholders like <EQUIP_NO>, <EQUIP_NO_PADDED> (18-char with leading zeros), <FUNC_LOC>, <SHORT_TEXT>, <LONG_TEXT>. You’ll still need a bit of local effort to wire transports, authorizations, CSRF handling, and adjust BAPI structures in your own system.
When I first had to expose SAP Plant Maintenance notifications as an API, I wasn’t an ABAP developer. I live in the world of APIs, Node.js, and microservices — not in SE80 or BAPIs. Still, with a little help from AI, I built a working SAP OData service that creates and retrieves PM notifications using the classic BAPI_ALM_NOTIF_CREATE.
This post is my path from “what’s a BAPI?” to a fully functioning OData endpoint that anyone can call from Postman or a modern front-end app.
🧩 The Challenge
We needed an API to create maintenance notifications (equipment breakdowns, inspection reports, etc.) from an external system into SAP.
SAP does ship a standard service (/sap/opu/odata/sap/API_MAINTNOTIFICATION), but it wasn’t enough. We needed custom validations, long text handling, and our own response messages. So I decided to build a custom OData service:
/sap/opu/odata/sap/ZSERVICE_PM_NOTIFICATION_SRV
The only problem? I’m not an ABAPer.
🧠 Step 1: Let AI Draft the ABAP Skeleton
I asked ChatGPT (my ABAP copilot):
“Generate an OData service to create a Maintenance Notification with Equipment, FunctLoc, ShortText, and LongText.”
It gave me the SEGW model and even named the right BAPI (BAPI_ALM_NOTIF_CREATE). In SEGW, I created the project and an entity Notification like this:
Field Type Description
MaintenanceNotification | Edm.String(12) Key | Notification No |
Equipment | Edm.String(18) | Equipment No |
FunctLoc | Edm.String(30) | Functional Location |
ShortText | Edm.String(40) | Problem Description |
LongText | Edm.String(1024) | Additional Notes |
Message | Edm.String(255) | Response Message |
Then I generated runtime artifacts → MPC, DPC, and DPC_EXT classes. So far, no manual code.
⚙️ Step 2: Let AI Build the CREATE_ENTITY Logic
The AI produced a clean version I pasted into
ZCL_ZPM_NOTIF_DPC_EXT → NOTIFICATIONSET_CREATE_ENTITY.
METHOD notificationset_create_entity.
DATA: ls_in TYPE zcl_zpm_notif_mpc=>ts_notif,
ls_out TYPE zcl_zpm_notif_mpc=>ts_notif,
ls_hdr TYPE bapi2080_nothdri,
lt_return TYPE STANDARD TABLE OF bapiret2,
ls_return TYPE bapiret2,
lv_notif TYPE qmnum,
lv_notif_c TYPE char12.
" Read payload from POST JSON
io_data_provider->read_entry_data( IMPORTING es_data = ls_in ).
IF ls_in-shorttext IS INITIAL.
RAISE EXCEPTION TYPE /iwbep/cx_mgw_busi_exception
EXPORTING message = 'ShortText is required'.
ENDIF.
" Optional but recommended: pad equipment to 18 (ALPHA)
IF ls_in-equipment IS NOT INITIAL.
DATA(lv_equ) = ls_in-equipment.
CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT'
EXPORTING input = lv_equ
IMPORTING output = lv_equ.
ls_hdr-equipment = lv_equ.
ENDIF.
" Map input to BAPI header
ls_hdr-descript = ls_in-shorttext.
ls_hdr-funct_loc = ls_in-functloc.
IF ls_hdr-equipment IS INITIAL.
ls_hdr-equipment = ls_in-equipment.
ENDIF.
" Call BAPI to create the notification
CALL FUNCTION 'BAPI_ALM_NOTIF_CREATE'
EXPORTING
notif_type = 'M1'
notifheader = ls_hdr
IMPORTING
number = lv_notif
TABLES
return = lt_return.
" Save and commit the notification
CALL FUNCTION 'BAPI_ALM_NOTIF_SAVE'
EXPORTING number = lv_notif
TABLES return = lt_return.
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING wait = abap_true.
" Format notification number
lv_notif_c = |{ lv_notif ALPHA = OUT }|.
" Prepare OData response
ls_out-maintenancenotification = lv_notif_c.
ls_out-equipment = ls_in-equipment.
ls_out-functloc = ls_in-functloc.
ls_out-shorttext = ls_in-shorttext.
ls_out-longtext = ls_in-longtext.
ls_out-message = |Created notification { lv_notif_c }|.
er_entity = ls_out.
ENDMETHOD.
Even though AI wrote the ABAP, I learned:
io_data_provider maps JSON → ABAP structure.er_entity sends back the OData response.BAPI_ALM_NOTIF_CREATE creates the record; BAPI_ALM_NOTIF_SAVE + COMMIT persists it.- Tip: Equipment often requires leading zeros (ALPHA) or you’ll hit “Equipment not found”.
🔍 Step 3: Testing the OData Endpoint
In /IWFND/GW_CLIENT, I ran:
POST /sap/opu/odata/sap/ZSERVICE_PM_NOTIFICATION_SRV/NotificationSet
Payload{
"Equipment": "<EQUIP_NO>",
"FunctLoc": "<FUNC_LOC>",
"ShortText": "<SHORT_TEXT>",
"LongText": "<LONG_TEXT>"
}
Response{
"d": {
"MaintenanceNotification": "100012345678",
"Equipment": "<EQUIP_NO>",
"FunctLoc": "<FUNC_LOC>",
"ShortText": "<SHORT_TEXT>",
"Message": "Created notification 100012345678"
}
}
That was the moment — the notification number finally showed up 🎉.
🧩 Step 4: Add a “View All Notifications” Endpoint
To list notifications, AI suggested BAPI_ALM_NOTIF_GETLIST. Minimal example:
METHOD notificationset_get_entityset.
DATA: lt_notif TYPE TABLE OF bapi2080_notif_list,
ls_notif TYPE bapi2080_notif_list.
CALL FUNCTION 'BAPI_ALM_NOTIF_GETLIST'
EXPORTING notif_type = 'M1'
TABLES notiflist = lt_notif.
LOOP AT lt_notif INTO ls_notif.
APPEND VALUE zcl_zpm_notif_mpc=>ts_notif(
maintenancenotification = ls_notif-notif_no
shorttext = ls_notif-descript
functloc = ls_notif-funct_loc
equipment = ls_notif-equipment
) TO et_entityset.
ENDLOOP.
ENDMETHOD.
Now I can hit:
GET /sap/opu/odata/sap/ZSERVICE_PM_NOTIFICATION_SRV/NotificationSet
…and get a clean JSON list of maintenance notifications.
🪲 Step 5: Debugging (with Help from AI)
When the notification number didn’t return, AI helped me debug like this:
- Set External Breakpoints in
ZCL_ZPM_NOTIF_DPC_EXT. - Use
/IWFND/GW_CLIENT → POST again to hit the breakpoint. - Watch:
ls_hdr-descript, ls_hdr-equipment, lv_notif, ls_out-maintenancenotification. - If it doesn’t stop, check:
/IWBEP/ERROR_LOG (Gateway errors)/IWFND/TRACES (payload/trace)ST22 (ABAP dumps)
Common fixes
- Equipment padding:
CONVERSION_EXIT_ALPHA_INPUT before calling the BAPI. - Wrong notif type: switch between
M1/M2 as per your config. - CSRF: fetch token first; then POST with token + JSON.
- Authorizations: ensure users can create that notification type/plant.
🧠 Lessons Learned (as a Non-ABAP Developer)
Lesson Explanation
| BAPI ≈ SAP’s internal API | Think of BAPI_ALM_NOTIF_CREATE as a function that writes a record. |
| ALPHA = OUT | Formats numbers with leading zeros for display (e.g., 1234 → 000000001234). |
| DPC_EXT | Where you write logic; like a controller in Node.js. |
er_entity = ls_out | Your OData response back to the caller. |
/IWFND/GW_CLIENT | SAP’s built-in Postman! |
🧩 Step 6 (Optional): Long Text
If your payload has long descriptions, add a helper:
IF ls_in-longtext IS NOT INITIAL.
me->add_qmel_longtext(
iv_notifno = lv_notif_c,
iv_longtxt = CONV string( ls_in-longtext )
).
ENDIF.
This will save long text into SAP’s long-text tab automatically (implement your helper with SAVE_TEXT).
🆘 Troubleshooting prompt (copy & paste into AI)
Use this when something fails. Replace placeholders with your values.
Prompt:
You are an SAP Gateway & PM ABAP/OData debugger. I have an OData service that creates PM Notifications. Analyze and give exact fix steps with code diffs.
Context
- System/SID/Client: <SID>/<CLIENT>
- Endpoint: <HOST>/sap/opu/odata/sap/ZSERVICE_PM_NOTIFICATION_SRV/NotificationSet (or V4 path)
- Action: POST create notification
- Error (verbatim): "<ERROR_TEXT>"
- /IWBEP/ERROR_LOG ID: <LOG_ID> (stack excerpt below)
- Payload JSON: { "Equipment": "<EQUIP_NO>", "FunctLoc": "<FUNC_LOC>", "ShortText": "<SHORT_TEXT>", "LongText": "<LONG_TEXT>" }
- Code snippet(s): DPC_EXT create_entity + NOTIFICATIONSET_CREATE_ENTITY
- BAPI flow: BAPI_ALM_NOTIF_CREATE → BAPI_ALM_NOTIF_SAVE → BAPI_TRANSACTION_COMMIT
Please verify
1) Equipment padding (ALPHA to 18 chars) and existence in EQUI/EQKT; try <EQUIP_NO_PADDED>.
2) Correct notif_type (M1/M2) and header mapping (funct_loc, equipment, short_text).
3) CSRF token and Content-Type; provide exact curl/Postman sequence if wrong.
4) Authorization/object checks for plant and notification type.
5) Number ranges if equipment creation fails (SNRO: EQUIP_NR, OIEN assignment).
6) Gateway exception mapping to /iwbep/cx_mgw_busi_exception messages.
7) If RAP/CDS path is used, handler create logic and service binding.
Artifacts
- ERROR_LOG excerpt: <PASTE_LOG>
- Code snippet: <PASTE_DPC_EXT_METHOD>
Deliver a concise fix with the exact ABAP line(s)/payload to change.
🎯 The Final Result
- A custom OData service
ZSERVICE_PM_NOTIFICATION_SRV - A POST endpoint to create notifications
- A GET endpoint to view them
- AI-generated ABAP that actually worked
- And a newfound respect for the SAP Gateway debugger 😅
🔮 Takeaway
You don’t have to be an ABAP veteran to build SAP OData services. With AI assistance, patience, and a few SAP debugging tools, even integration engineers can craft end-to-end APIs that interact directly with the core system.
Author: Sayantan Tarafdar
Title: How I Used AI to Build an SAP PM Notification OData API (as a Non-ABAP Developer)
Tags: #SAPBTP #OData #BAPI_ALM_NOTIF_CREATE #PlantMaintenance #Integration #ABAPForNonABAPers
Bluesky
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.