Posted on SCN at http://scn.sap.com/community/abap/blog/2014/07/28/understanding-and-modifying-migos-defaults-programmatically.
Recently I had a situation where I needed to update MIGOs defaults programatically. I tried to search for a solution but couldn’t see it mentioned anywhere and hence decided to write it down . I hope that it’ll be useful for anyone in a similar situation.
MIGO is a multi-purpose transaction which can be used for various activities in material management – performing goods movements, receipt of purchase order etc. It replaces many older transactions . There are others as well but to list down a few:
- Post a goods receipt to a known purchase order (transaction MB01)
- Change a material document from goods receipts (transaction MB02)
- Display a material document from goods receipts (transaction MB03)
- Cancel a material document from goods receipts (transaction MBST)
To understand why we may need to ever need to modify MIGO defaults, consider the below situation.
– A file arrives for processing in SAP ( say as a batch job ) .
– Initial goods movement is tried using a BAPI. If the processing fails , a user SM35 BDC session is created for processing which can be reprocessed by users ( the users are familiar with MIGO ). A custom transaction for reprocessing is created as the users couldn’t be given access to SM35. SM35 allows you to display and potentially reprocess all sessions which can be tricky if the authorisations are a bit leaky.
The failed sessions can then be processed by a custom transaction – the SM35 sessions are persisted to a temporary table to be used by reprocessing transaction.
Everything looks good in theory : all automatic postings are done in background and any errors can be handled by the custom transaction. However, while the user is performing the reprocessing the MIGO session, something interesting happens – if the user opens a parallel MIGO session and performs some other processing in parallel, the subsequent sessions start to fail in the custom transaction. Users could be processing multiple sessions sequentially and might go away and do some other movements in parallel in MIGO.
Why does this happen ?
MIGO stores user’s defaults trying to optimise the usage so that the user doesn’t have to set the selections – this causes the defaults to be always set whenever you use the transaction. The parallel session which the user opened has overridden the defaults and as a result, subsequent failed sessions have different default values set in the screen even though the BDC recording used in SM35 session was set correctly. User defaults is overriding BDC set values .
Looking at the below image, the BDC session has set values A07 and R10 for action and sub-selection within action.
However, if the user choses something else in a parallel session ( say A05 and a sub-selection ) , it overrides the action default and subsequent SM35 sessions start failing as then MIGO will start with A05 / sub-selection.
MIGO stores user’s defaults in table ESDUS and these defaults correspond to MIGO_FIRSTLINE action. Seeing the below table entries, the settings for the user are:
Default is action = A07
and sub-selection for A07 is R10.
Hence, A07 / R10 will appear for ACTION and sub-selection ( as shown in above image ) .
Show Me The Code:
Now, we know where they’re stored, how to update them ?
Class CL_MMIM_USERDEFAULTS can be used to read and update the parameters. It’s a singleton and hence there should be only instance at a given time. Consequently, if we’re using it we have to ensure the instance is destroyed . This is achieved by FLUSH_ALL method of the class. Above methods are self explanatory and the constructor requires ACTION value.
So I did the following:
– Instantiate the class using ACTION as “MIGO_FIRSTLINE” and set the instance values.
– Set the values:
( i_element = ‘ACTION’
i_active = lv_action ).
– Flush the value to dB and destroy the instance
o_migo_defaults->flush( ). “Save values to dB
o_migo_defaults->flush_all( ). “Destroy this instance as others instance will start producing errors
The table has other values used in MIGO defaults ( e.g. default movement type for an action ) and can be similarly updated.
Main features of SMP 3.0 :
– SUP, Agentry and Mobiliser combined. This itself is a pretty big as each of the platforms had an integration framework and it had to be harmonised . It’s simplified to just use SMP with services exposed in oData format.
– Through SMP 3.0, services from ABAP backend ( using SAP Gateway ) and non SAP backends can be easily consumed. This is pretty powerful as data could be spread out over multiple kinds of data sources. It allows for data consumption from JPA, JDBC , SOAP etc.
– Eclipse GWPA has been enhanced for new features – to consume services from different backend types.
– A big drawback I see is that it doesn’t seem to talk about MBO based replication. My first iOS mobility project involved creating an iOS ( iPAD app ) using SUP which was based on MBOs and it’s sad to see them go. Support for offline capabilities is planned from later releases of SMP 3.0.
– A big positive is the ability to schedule different data based on speed ( or other requirements ) – the ability to assign priorities in scheduling is a big one – our users were extremely frustrated that they can’t control the information they wanted and had to wait for sync of everything from past before relevant data for today could be synced.
Comparisons between SAP Gateway and SAP Integration Gateway:
– ABAP based vs Lean Java server ( Java, OSGI ).
– Supports SAP vs Supports both SAP and non-SAP data sources.
– Available as a standalone solution vs embedded inside SMP 3.0 .
– On premse vs On premise / Cloud.
One hack I have been using a long time for educational videos on youtube.
Sometimes, the default speeds are not good enough – 1x is too slow and 1.5x is too fast . change it to 1.25x .
document.getElementsByTagName(“video”).playbackRate = 1.25