Skip to Content

From Functional to Technical – Part 3                >>

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.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Anna Geernaert
    Hello Somnath,
    as you write in your blog “(in case someone needs to build somethiing similar)”. I am one of those person who need to create something very much like what you describe. Thanks for sharing this knowledge with us.
    But, about the function module enqueue_read, I see in our system that the GARG value is allocated dynamically in the lock entries for those with GNAME= /SAPAPO/OMSIMSDL. I don’t have entries in SM12 where I see the planning area id as GNAME. Thus, it is not possible for me to distinguise between out three different planning areas. Is this a flaw in SM12? Is it possible to do configuration to get a lock entry where it is possible to distinguish the planning area name?

    regards
    Anna

    (0) 
    1. Somnath Manna Post author
      Hi Anna,
      In SM12 there should be multiple entries for each user locking up the Planning Area. Aaprt from the GNAME=/SAPAPO/OMSIMDL there will be a set of entries as /SAPAPO/DM_PAREA_LOCK which should give you the Planning Area technical name in GARG. I think the GARG value against GNAME=/SAPAPO/OMSIMDL is the dynamically generated PLOB id. ITs not relevant for finiding the planning Area.
      Hope this helps.
      Somnath
      (0) 
    2. abhishek sharma
      Hi Somnath, Anna,

      I am facing the same issue as mentioned by Anna. I dont see the value “/SAPAPO/DM_PAREA_LOCK” as the result of ENQUEUE_READ. I am rather seeing LCA_GUID_STR and /SAPAPO/OMSIMSDL in GNAME.

      We are on SCM 5.0 currently. What could possibly be the issue?

      Thank You.

      Cheers!
      Abhi

      (0) 

Leave a Reply