In my From Functional to Technical – Part 3 blog I mentioned how at my current project we Functional Analysts end up almost (!) writing the Technical Spec. But over last week and yesterday there has been a change which I want to share in this blog. There was a technical requirement coming from a recent Go-Live issue. We have a Planning Area for Global Supply Network Planning and every night (there is no night unfortunately after recent US Go-Live) it is reinitialised in a background job. Unfortunately the job cancels if there is a lock at any level in the Planning Area. The lock comes due to users being in Change Mode in Interactive Planning. Once the root cause of the issue was nailed down, it was time for a quick enhancement design, development and testing to move the solution to Production.
So we started off race against time to come up with a solution. I had come across a similar issue at my earlier client so a quick search of my personal notes gave me some pointers to function modules that can be used to a) find out locks in the system. But we needed to find function modules to b) send system popup messages to users locking the planning area so that they have a chance to move to Display mode and c) to kick out user sessions who have not heeded the warning.
Here is the list of Function Modules used (in case someone needs to build something similar)
a) ENQUEUE_READ Pass Planning Area value as GARG and PAREAID as GNAME to get information about lock entries for selected planning area. GUNAME corresponding to GNAME = /SAPAPO/DM_PAREA_LOCK and GOBJ = /SAPAPO/E_PAREA entries provides user id (s) locking the planning area displayed in the field GTARG.
b) TH_POPUP to send out popup messages to the users locking the Planning Area.
c) TH_DELETE_USER to kick off users (GUNAME) who have been locking the planning area.
The basic report was developed pretty quickly and tested without a problem. But the next challenge was to send out notification to all the “relevant” users logged into the system. My Technical Analyst started quizzing me as to how we can determine the “relevant” users. Functionally only Demand and Supply Planners will need to be notified and a quick analysis of the Composite Roles assigned to these Business Users gave a clue. We managed to determine a single Authorisation Object C_APO_IOBJ with Change (02) ACTVT is common to these two roles and its not there in any of the other roles (though Display 03 was).
So back to drawing board with my Technical Analyst quickly coming up with Function Module SUSR_PROFILE_SELECT to determine the “Security Profiles matching to the above-mentioned Authorisation Object and Field value. Then function module PRGN_ACTIVITYGROUP_PROFILE_GET get to matching roles while another function module PRGN_READ_USERS_FOR_ONE_AGR gave the list of users in the system matching those roles. Yet another function module TH_USER_LIST gave the list of users currently logged in the system. Then its just sending popup message to these “relevant” users logged in system using function module TH_POPUP.
Well we finished development and testing in the last day of 2008. In the spirit of New Years Eve my Technical Analyst send out a test message urging users in Development System (we Project Team only) to log off from the system and enjoy New Years Eve. We all promptly logged off and left for the day 🙂
Wish you all HAPPY NEW YEAR 2009.