cancel
Showing results for 
Search instead for 
Did you mean: 

SLFN verses SDTM in Test Workbench

Former Member
0 Kudos

We are in a new implementation project using the test workbench (STWB_2) on our development and test systems. We are newly implementing CHARM and trying to understand an apparent inconsistency or lack of integration.

CHARM help documentation reads that the SDTM Test Message transaction is used to report problems back to the developer discovered in testing. This transaction type requires no change approval before creating new transport requests and development since it is already sanctioned development.

Logging defects in the test workbench (STWB_WORK) calls notif_create to create an SLF1-SLFN support message. The CHARM help documentation shows the process flow for SLFN as next going to a change request for approval and then change document before further development.

On an implementation project, defects found in testing and logged through the test workbench are sanctioned development requiring no approval. The approval loop is inefficient overhead in this situation. It seems that test defects logged in the workbench for implementation projects should trigger a fast path transaction type like SDTM.

Changing the behavior of notif_create to trigger a different document type in this situation does not appear to be an easy change.

It appears that we are misunderstanding something, or CHARM is not integrated with the test workbench. Any insight you can provide is helpful.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi Karl,

it is quite easy: Use transaction "dno_cust04" and change (or add) the entry called "PROCESS_TYPE" from original value "SLFN" to "SDTM". Then from all triggers (e.g. test workbench or satellite systems) a Test Message will be created instead of a Support Message.

However the message creation mask in STWB_WORK will ask for the attributes of a SLFN support message - but the system creates a SDTM test message. Result: The values that are entered in the mask are not transferred to the SDTM message - you have to fill them in again...

So I suggest that you still use SLFN (or ZLFN...) messages in the test workbench, and from those SLFN messages, you create a SDTM as a follow up message, if a change in the system is required!

(for content copying see also this thread:

)

Hope this clarifies.

Best regards

Christoph