As we know the UWL provides us (as end-users) with a centralized point of access to work-items and work-tasks which can vary from simple admin queries to functional approval processes. From an organizational standpoint the management of such work-items is of vital importance towards conformance to key business requirements and processes.
If the UWL is being utilized to manage supplier purchases (SRM) and involves interaction from a key set of employees who operate through an approval process substitution is a term of strong relevance. Organizations and business establishments that share business relationships will need to manage communication with diligence regardless of consistently. End-Users share an obligation to ensure work commitments and task processing requirements are fulfilled during their vacation time so all involved parties are formally fulfilling business requirements even in the absence of another employee.
UWL Substitution Issues
In my experience I have encountered a wide range of different issues in association to Substitution Processes and their utilization alongside the Universal Worklist (UWL). For example if you are utilizing the Universal Worklist and presently have configured a substitution rule which is no longer valid e.g. the assignee is no longer with the company you may encounter issues. On some occasions despite you’re best efforts you seem not to be able to fix, delete or remove the substitution rule.
With such an occurrence exceptions can be quite generic and may sometimes grammatically appears as:
- “Cannot Connect to Provider ” or “Problems Reported (Repairable).
“No Substitution Could Activate this Substitution Rule”
Lets take a working example and imagine that in an organization a single user is not able to manage substitution rule from the UWL portal interface. Instead he/she begins to receive the error “No system could activate this substitution rule” when attempting to configure and save the rule.
How could such an issue arise?
The first question which needs to be brought under the limelight here is whether or not the user who is encountering the issue has been deleted/disabled? If the user has been deleted this is known to cause some inconsistencies and subsequent discrepancies in a system setup. For this reason it is always recommended to Disable a user as opposed to delete them. From a logical standpoint if you go ahead an proceed to delete a User who is part of any process flow any tasks maintained in association to such a user will become invalid hence the importance of disabling the user.
With Substitution in general from a high level perspective there are some important points to highlight and keep in mind.
- One key point is that Substitutions are kept in all systems.
When a substitution rule has been created either in the backend or in Java Workflow, Universal Worklist will try to activate the substitution rule in ALL available connector(s), be it WebFlowConnector, AdHocWorkflowConnector or BPEMUWLConnector.
In the case where the user whom a substitution rule is being maintained is not mapped or does not exist in one of the systems defined, then the Universal Workflow will report that inconsistency through the “Problems reported(repairable)” or a message in “Manage Substitution Rules” – > “My Substitution Rules” – > “Rule Activation” status.
- You will see the coded fix for this particular issue in SAP Note: 1851579 – UWL Substitution Status error message has technical details
Substitution & Databases
In the past on several occasions I’ve worked on scenarios in which manipulation i.e. deletion has taken place from a DB Standpoint in an effort to resolve UWL and substitution issues. Again I would like to reaffirm what has been highlighted above and stress the importance of not deleting User Profiles or references until all necessary steps have been taken.
If you have been researching ways to resolve substitution issues then you will have of most likely come across the following DB References:
- HRUS_D2 table
Kindly allow me to provide some clarification here.
The general method to delete a substitution revolves around checking the entries in Database table KMC_WF_SUBSTITUTE in Portal DB and then subsequently deleting any entries against the user.
- Remember: Substitutions are kept in all systems
Firstly the Backend table HRUS_D2 stores all the current substitutions. The moment the rule is deleted/disabled then the entry gets deleted from this table. In terms of worktasks and their associated tables these will store the classification of tasks, and fields such as TCLASS contains the classifications and the task name.
Again referencing the HRUS_D2 DB Reference. This table contains the approver, the substitute, the begin and end dates, the substitution profile and whether the substitution is active or not.
Now regarding the HRDUS_D2 table and delegation. With this table we should NEVER manually delete or manipulate records from both HRUS_D2 and KMC_WF_SUBSTITUTE.
- The HRUS_D2 is a database table which does not belong to UWL and we should never advise manual deletion on it or manipulation. SAP_WAPI_SUBSTITUTE_MAINTAIN is the function module as you suggested used for maintaining substitutions in the backend.
So regarding KMC_WF_SUBSTITUTE as database table this database table contains data in relation to substitution for the Universal Worklist specifically relating to the AdHocWorkflow Connector. If you are facing an issue with substitution from the Universal Worklist, you may be asked to check this table.
For a more comprehensive overview I recommend reviewing the following SAP Note: 854549 – Scope and behavior of substitution in UWL