BAPI_NETWORK_MAINTAIN — BAPI_NETWORK_MAINTAIN for Network and Activity Maintenance
BAPI_NETWORK_MAINTAIN creates or changes a Project System network together with its activities, relationships and milestones in a single call, mirroring transactions CN21/CN22. It uses paired method and data tables to control create/update/delete per line, returns results in a BAPIRET2 table, and requires an explicit BAPI_TRANSACTION_COMMIT because it does not commit on its own.
This page covers what BAPI_NETWORK_MAINTAIN does against the network business object, the method-driven parameter structure it uses, and why callers who skip the RETURN table or the commit step end up with half-built networks. It also covers the interface bugs that recur in integration builds and who owns them.
Published 16 Sept 2026· 1,041 words
What it does
BAPI_NETWORK_MAINTAIN acts on the Project System network object: the network header, its activities, activity relationships and milestones. It is the API equivalent of transaction CN21 for network creation and CN22 for change, and is normally called from custom interfaces, data migration programs, or integration scenarios where networks need to be built from an external planning or scheduling system without a user sitting at CN21. A single call can create the network header, add several activities under it, link them with relationships, and attach milestones, all in one pass. It does not replace the standalone activity or relationship BAPIs used for narrower changes; it is the object-level maintenance API for the whole network structure at once.
Important parameters
The interface is built around method tables paired with data tables, the same pattern used by BAPI_PROJECT_MAINTAIN: each method line tells the BAPI whether to insert, update or delete the corresponding data line.
- METHOD_NETWORK - one line per network, carrying the operation code (create, update, delete) and the network key the following data table lines refer to
- NETWORK - the network header data: network type, plant, MRP controller, dates, and other header-level fields
- METHOD_ACTIVITY - operation code per activity line, keyed to the network and an internal activity reference number used before the real activity number exists
- ACTIVITY - activity master data: activity type (internal, external, service), control key, work center, durations, and cost-relevant fields
- RELATION - proposed relationships between activities, referencing the internal activity reference numbers rather than final numbers
- MILESTONE - milestone data attached to activities where used
- RETURN - the BAPIRET2 return table carrying all messages, warnings and errors generated during the call
Commit behaviour
Like the rest of the classic Project System BAPI family, BAPI_NETWORK_MAINTAIN does not commit the database update itself. It builds the network structures in the update task and leaves the commit to the caller. If BAPI_TRANSACTION_COMMIT is not called afterward, the changes are rolled back at the end of the session or the RFC call, and the caller is left believing a network was created because RETURN showed no errors, when in fact nothing was ever written to the database. In batch interfaces this shows up as data that exists during the run, is visible in a test read within the same LUW, and is simply gone the next day.
Return handling
RETURN is a table, not a single flag, and every line in it needs to be evaluated against its TYPE field for E or A messages, not just checked for whether the table is empty. Checking only the function module's own SY-SUBRC after the RFC call is useless here since that reflects communication success, not business success. A frequent interface bug is treating one clean-looking success message on the header line as proof the whole network went in, while an activity or relationship line further down the table carries an error that stopped that piece from being created. Because the BAPI processes network, activity, relationship and milestone data in the same call, a partial failure can leave the header committed with some activities missing, and nothing about that is obvious unless every RETURN line is walked and correlated back to its ID field to identify which object it refers to. Interfaces that log only the first message, or that summarise RETURN as pass/fail, routinely miss this and report false success upstream.
ECC vs S/4HANA
BAPI_NETWORK_MAINTAIN remains in use on S/4HANA and is still the standard programmatic way to create or change networks outside the CN21/CN22 transactions. There is no released, feature-complete OData or API-based replacement covering the full network-plus-activities-plus-relationships scope this BAPI handles in one call; where newer APIs exist for Project System objects, coverage tends to be partial rather than a drop-in substitute. New integration builds should still check what is currently released for the specific S/4HANA version in use before assuming this BAPI is the only option, but it has not been withdrawn.
Common pitfalls
Most production issues trace back to the internal reference numbering scheme or to configuration the BAPI does not validate for the caller.
- Relationships reference activities by an internal number assigned by the caller in the same call; a mismatch between that number and what was used in ACTIVITY silently drops the relationship with no header-level error
- Network created but individual activities rejected because work center or control key does not match the network's plant or network type configuration in the underlying network profile
- Costing-relevant fields left blank because the caller assumed CO integration runs automatically inside the BAPI when it actually requires a subsequent explicit call or a save
- Duplicate network creation when a retry logic resubmits the same payload after a timeout, because the BAPI has no built-in idempotency check against an external key
- Activities created without a valid MRP controller or scheduling parameter, causing downstream capacity or procurement processes to fail even though the BAPI itself returned no error
Whose problem this is
Interface bugs around missing commits, mis-parsed RETURN tables, and internal reference number mismatches sit with the developer maintaining the call. Configuration-driven rejections, such as a control key not permitted for the activity type or a work center not assigned to the network's plant, are functional PS configuration issues and need the network profile and activity type settings checked before the interface is touched again.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-bapis/bapi-network-maintainERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.