Api to set trigger point for an operation CA02

[#1]

Hi everyone,
I am looking for a BAPI, Function Module...  that can be used to create or set a trigger point for an operation, with the same behavior as when maintaining the trigger point manually in CA02.
The requirement is to develop a custom API (segw) that should be able to set the trigger point for a specific operation in a routing .
I have searched for relevant BAPIs/function modules but haven't found a clear released fm that performs the same operation as CA02. 
Does anyone know of a standard BAPI, FM, .... that can be used to create/set an operation trigger point programmatically?
I would also appreciate any guidance on which standard SAP classes/function modules are used internally by CA02 for maintaining trigger points, or the recommended approach for implementing this without directly updating the database tables.
Thank you

[AlexandrePassarelli]

Hi,

Short answer: there is no BAPI, released function module or API that creates or changes a trigger point on a routing operation. I checked the standard objects on an S/4HANA 2020 system and on a newer release (read-only). The only way that runs exactly the CA02 logic is a batch input of CA02 itself.

Where trigger points are stored

• Table MLST (the same milestone table used by PS), texts in MLTX.
• Key: MANDT + MLST_ZAEHL + ZAEHL. MLST_ZAEHL comes from a number range (CN_MS_MLST_NUMBER_GET_NEXT), ZAEHL is the version counter.
• Link to the routing: PLNTY, PLNNR, PLNAL and PLNKN (the operation node). AUTYP = '10' for routings ('20' for standard networks).
• Change management fields: DATUV, AENNR, LOEKZ.
• The functions are the RELSU, RELMS, INCPN, INCNW, INCSN and WKFLW fields with their status fields.

What CA02 uses internally

• CA02 runs program SAPLCPDI (screen 1010). In function group CPDI, FORM MST_EDIT (include LCPDIFM1) calls CN_DI_MST_INSERT for a new trigger point and CN_DI_MST_UPDATE for a change. Trigger points copied from a standard trigger point go through the same CN_DI_MST_INSERT (LCPDIFI1 and LCPDIFW2).
• CN_DI_MST_INSERT (group CNDI) gets the number, appends the record to the buffer with CN_BT_MLST_APPEND (group CNBT) and inserts it into the CP dialog table. Its interface needs INDEX_PLKO, INDEX_PLFL and INDEX_PLPO of the dialog tables, so it does not work outside the CA02 dialog.
• On save, FORM PLAN_UPDATE_TO_DB_PROC (LCPDIFP1) calls CN_BT_MST_UPDATE_TO_DB, which calls CN_VB_MLST_POST IN UPDATE TASK. This only happens if the task list type allows milestones (TCA01-FLG_MST).

What I checked and why it does not help

• BAPI_ROUTING_CREATE: creates a new routing only, its tables have no trigger point, and there is no change BAPI for routings.
• CP_CC_S_* (Engineering Workbench API, group CPCC): for milestones only CP_CC_S_MST_PROVIDE_BY_MTK (read) and CP_CC_S_DELETE_BY_MST (delete). Nothing to create or change, and none of them is released.
• API_PRODUCTION_ROUTING and the RAP routing BOs: no trigger point or milestone entity in any version I looked at.
• CN_DI_MST_* / CN_BT_*: they do the work, but they depend on the CA02 screen context and are not released.
• The standard routing load programs RCPTRA01 (batch input) and RCPTRA02 (direct input) only cover header, sequence, operation, PRT, inspection characteristic, component and text. No trigger points.

Recommended approach

In your SEGW DPC method, record CA02 in SHDB and run it with CALL TRANSACTION 'CA02' USING lt_bdcdata MODE 'N' UPDATE 'S' MESSAGES INTO lt_messages, then map the messages to the OData response. This goes through MST_EDIT, the buffer and CN_VB_MLST_POST with all checks of the transaction. If you work with change numbers, fill the change number on the CA02 initial screen, since MLST keeps AENNR and DATUV. How the change number behaves for trigger points depends on customizing (ECN_MST), which I did not check.

You are right to avoid writing MLST directly: that skips the number range, the change documents and the update task.

Two caveats: a batch input depends on the screen layout, so test it after upgrades, and I did not test the CALL TRANSACTION from inside a Gateway service, only read the source.