This blog is part of a series on how to control document changes in Solution Manager. Here, I describe how to configure a release strategy for the approval and subsequent release of documents.
When creating a document, the status will be IN PROGRESS. A release strategy for releasing the document should require an electronic signature by the author when moved to status REVIEW, and because the document can’t be signed twice by the same person, another signature will be required to put the document into RELEASED (or DECLINED) status. Figures 1 to 3 show the expected process in Solution Manager.
Fig. 1 Change status from In PROCESSING to REVIEW.
An electronic signature is required from PKISLOFF
Fig. 2 Display document and then approve change.
An electronic signature is required from PKISLOFF2. The reject icon is at the bottom, where comments can be added.
Fig. 3 Comments can be display in history tab, by clicking on the Display comment link (row highlighted).
Electronic signature set up depends on two transactions, STRUST (Figure 4) and SSFA (Figure 5), details in IMG path SAP Solution Manager > Scenario-Specific Settings > Cross Scenario Settings > Digital Signatures > Signature Strategy
Fig. 4 Create an entry in transaction STRUST for SSF Standard Applications
Fig. 5 Add the standard apllication in transaction SSFA for SSF SAPSECULIB (needs to be present at O/S level).
Note that although the use case I mentioned in the introduction to this blog series was for FDA regulated requirements, I’m not showing how to implement application PPPI which is designed specifically for that. These electronic signatures will just prompt for the user password to allow a status change to the document.
Now for the configuration of release strategies. The IMG path to follow is SAP Solution Manager > Scenario-Specific Settings > Cross Scenario Settings > Document Management > Strategy for Documents
Before I describe the configuration of the release strategy, let me describe what it is first. There are only two approvers, the author of the document (because the author once they have released it for approval, can not release it a second time e.g. for approval) and the reviewer. There are many document types that will need approval, but I have grouped them into four major groups, Project, Functional, Development and End-user (see Fig 5). In my release strategy, the reviewers are the team leader(s) for each group.
Fig. 5 Example grouping for document types to be used for signature strategy allocation
Thus in configuration, I will set up four pairs of release agents:
P_AUTHOR and P_REVIEW for Project documents
F_AUTHOR and F_REVIEW for functional documents
D_AUTHOR and D_REVIEW for development documents
U_AUTHOR and U_REVIEW for end-user/training documents
In this example, F_AUTHOR and F_REVIEW user signature strategy FUNCTION. In Fig 6 for configuration entries, a system signature is required, and as defined in transaction SSFA this is the user password. The author F_AUTHOR has to sign the document before the reviewer F_REVIEW, and once both have done so the document is released.
Fig. 6 Release strategy configuration
The various statuses and sequence are define in the status schema, after which it must be assigned to the document types to group them as defined in Figure 5. This is found in the project standards project template.
Fig. 7 Project standards template define status schema for document types.
Authorisation object C_SIGN_BGR uses AuthGrpDS = Stat.Schma
One final word. If done correctly, release of documents using a properly configured release strategy automatically creates a workflow event (see Fig. 8).
Fig. 8 Output from workflow event logging transaction SWEL
Many people think this can only be generated from an enhancement point, but in the next blog I will show how we use the enhancement point to automatically calculate the next version number every time a document is released.