Digital Signatures in SAP PLM 7.x
This blog is intended as a source of information adding to the generic documentation available on digital signatures in SAP PLM 7.x. The blog is mostly influenced by personal experiences in implementing SAP PLM 7.x and digital signatures in a controlled environment. For a proper introduction on the technology involved see Digital Signatures for SAP Applications Using the Digital Signature Tool – Developer Guidelines and Best Practices by Uwe Dittes which is an excellent source of information regardless in which context you intend to implement digital signatures. I’m not going to repeat any information contained in Uwe’s document so if you don’t understand everything in this blog, Uwe’s presentation is probably where you should start.
In SAP PLM 7.x the implementation of digital signatures is based on Web UI which is basically a bunch of Web Dynpro ABAP applications leveraging Floorplan Manager for Web Dynpro ABAP and the Service Provider – Service Provider Infrastructure (SPI) – SCN Wiki framework. Without going into the details of both frameworks, the take away here is that there are several integration levels that you need to consider, especially if you are looking into enhancing the standard SAP implementation. The lowest integration layer is the DMS one dating back to pre Y2K which is fairly well documented.
When the status network is configured to require a digital signature, the Signature button becomes available in the Web UI. Once you press on the Signature button, method CALL_SIGNATURE_POP_UP of the Component Controller of Web Dynpro Component /PLMU/WDC_DIR gets called. Once the popup is closed, method HNDL_SIGN_POPUP of ABAP class /PLMU/CL_DIR_APPL_ASSIST gets called. First thing you should know about the method is that if you plan to enhance it, you first need to make it enhanceable in transaction SE24.
Once the signature is verified, it is stored in the database and the new document status is changed by triggering the event DIR_SAVE.
Generally speaking on digital signatures, the signatures are saved in the tables SIGNH (header) and SIGNS (item) as well as DRAW_DS. When the signature is commited, table DRAP gets also updated. For every status requiring a digital signature, there will be a respective digital signature in the database assuming one was given. The key here is the status counter STZAE both in database table DRAP as well as DRAW_DS. If a signature for a specific status counter doesn’t exist in the system, it is considered either as not given (normal case) or missing (interrupted or corrupted case). For every signature status in DRAW_DS you will find a respective signature in database tables SIGNH and SIGNS assuming everything went smoothly. The key field SIGN_ID can be used to link table DRAW_DS to SIGNH/SIGNS.
The problem with the current implementation is that it is very disconnected meaning if any step should fail, several layers need to be cleaned up which is very error prone and according to my own experience isn’t handled too well in the standard SAP system.