Altius Community

Altius Consulting Community
Welcome to Altius Community Sign in | Join | Help
in Search

Glen Chambers

March 2008 - Posts

  • SAP GUI 6.40 Discontinued Support

    At a major worldwide client I am currently working for it has recently been noted that their standard SAP GUI client (version 6.40 patch 24) is out of support from 14th of October 2008, a date that looks very close when you consider the thousands of clients that need to be upgraded!

    SAP GUI is SAP's universal client for accessing SAP functionality in SAP applications such as - SAP ERP, SAP Business Suite (SAP CRM, SAP SCM and SAP PLM), SAP Business Intelligence and so on.  SAP GUI functions like a browser. It gets information from the SAP server like what, where, when and how, to display contents in its window.

    image
    The primary reason that SAP are discontinuing support on this date is that the development environment of GUI, Microsoft Visual Studio 2003, will not be supported by Microsoft anymore.  So what are your options?  SAP released SAP GUI 7.10 in 2007 but given SAP's history of support packs it was wise not to upgrade immediately, unless of course you use Windows Vista when you had no choice as 7.10 is the only GUI that supports that operating system.

     

    image The good news is SAP GUI 7.10 for Windows is downward compatible with any existing SAP systems you have. You can use, for example, SAP GUI for Windows 7.10 with R/3 3.1, 4.0, 4.5, 4.6 so you can freely upgrade SAP GUI without upgrading your SAP systems.  Support for version 7.10 is scheduled to last until March 31st 2011 and it supports all versions of Windows from 2000 - Vista.  The latest patch version at the time of writing is 7.

    Some of the key new features you can expect in SAP GUI for Windows 7.10: (From SAP Note 947334)

      • New ABAP front-end editor
      • Enhancement of the existing icons
      • New SAP Logon interface with wizards for inserting and managing system entries
      • "Tweak SAP GUI" - Tool for creating central settings for all relevant display options in the SAP GUI (for example, design, colours, fonts and so on)
      • The accessibility mode provides shortcuts that you can use to activate input fields directly.

    You can download SAP GUI 7.10 from ftp://ftp.sap.com/pub/sapgui/win/710/compilation1/ 
    and the latest patch from  ftp://ftp.sap.com/pub/sapgui/win/710/patches/

    As always it is strongly advised that you test the new GUI on a dummy machine before rolling it out!
    More information can be found from SAP here: Updated Support Matrix- SAP GUI for Windows (SAP service login required)

  • InfoCube Partitioning

    So what is partitioning and why do it? 

    You use partitioning to divide the data in an InfoCube into multiple, smaller, independent and related segments.  This separation improves system performance when performing data analysis InfoProvider, this is because the system knows only to read a particular part of the disk to retrieve the data you are after.  In addition it can perform parallel data reads of multiple partitions speeding up the queries execution time.  There are always two extra 'catch all' partitions created as well as the ones you explicitly specify in order to store all of the low and high values that fall outside of the normal range, as shown in the example below:

    cube 2

    What partitioning options do you have?

    Physical Partitioning

    Physical partitioning is done at database level and is can only be based on one of the following date based criteria: Calendar Month (0CALMONTH) or Fiscal Year/Period (0FISCPER).  

    An increase in performance is only seen for the partitioned InfoCube if the time dimension of the InfoCube is consistent.  In the standard example shown on the right only the first record is consistent.

     

    2008-03-11_002059

    To setup partitioning for an InfoCube, choose Extras -> DB Performance -> Partitioning and specify the value range. Where necessary, limit the maximum number of partitions, the SAP recommended optimal maximum number of partitions is 30-40, so consider this when planning the range spilt.  All changes are transparent for the user and behind the scenes you still have one logical database table.

    In BW 3.5 you had to setup partitions whilst the InfoCube was empty but this constraint has disappeared in BI 7.0 (for all database providers except for DB2).  In 7.0 it is not only possible to partition whilst the InfoCube has data but also re-partition any existing groupings.  Repartitioning can be useful if you have already loaded data to your InfoCube and you have loaded more data into your InfoCube than you had planned when you partitioned it, you did not choose a long enough period of time for partitioning or some partitions contain no data or little data due to data archiving over a period of time.

    You can access repartitioning in the Data Warehousing Workbench using Administration, or in the context menu of your InfoCube.

    Logical Partitioning

    Logical portioning is done at the data level and is achieved by separating out related data into separate InfoCubes that are joined into a multi-cube.  In this case the related groupings are not solely restricted to time only, although by year would be a sensible choice, you could partition by plan and actual data, regions or business area.  All queries based on the multi-cube will automatically use parallel sub-queries as required to retrieve the result-set thus improving query performance.

    Cube

    Conclusions

    For anyone involved in planning solutions the logical partitioning will already be part of everyday life for comparing Plan vs Actuals data but other InfoCubes that contain a fair amount of data could benefit from being split into smaller cubes by for example year.  Not only will this bring performance benefits but also make it easier to archive old unused data. 

    In BW 3.5 many cubes were partitioned at their point of creation but maintenance was a real issue and many were left with inadequate ranges over time, now this problem has been addressed in BI 7.0 it should be much easier to keep the systems running in a optimal state and well worth investigating.

  • Loading Master Data without using the PSA in SAP BI 7.0

    I'll start with a quick refresher of the PSA; the Persistent Staging Area (PSA) is the inbound storage area for data from source systems coming into the system. The requested data is saved in relational database tables in the same format as the DataSource.  The data held within the PSA remains unchanged from the source system, meaning that no summarization or transformations haven take place (as is the case with for example InfoCubes).  image

    In BW 3.5 you had the option of loading data directly to InfoProviders completely by-passing the PSA all together, however this all changed with the release of BI 7.0.  In version 7.0 it has become mandatory to use the PSA for all data loads, there are in fact many good reasons behind this change.  One such example would be if one set of data is destined for two different InfoProviders both with different transformation requirements, then previously you could of loaded the data twice from transactional source system if you skipped the PSA, thereby putting undue stress on that system when dealing with large volumes of data.  By using the PSA the same set of data can be read from within the SAP BI system time and time again reducing the impact on underlying source systems.

    If you are loading small amounts of master data and want to avoid using the PSA for example when you are testing things in your sandbox there is a way;  in data transfer process (DTP) maintenance, you can specify that data is not extracted from the PSA of the DataSource but is requested straight from the data source at DTP runtime. The (rather long!) Do not extract from PSA but allow direct access to data source check box is displayed for the Full extraction mode if the source of the DTP is a DataSource.

    image

    By using this method you do-not have to create an InfoPackage to extract data from the source system.

    Some things to bear in mind though:

    • Data is extracted synchronously - as in while you wait, hence it advises small data loads only, this does increase pressure on the systems memory
    • If errors occur during the data load you have to extract the data again as the PSA is not available as a buffer.
    • Deltas are not possible, only full loads.
    • In the DTP, the filter only contains fields that the DataSource allows as selection fields. If you use the PSA, you can filter by any available field.

    Despite all of the above I find it to be a real time-saver and useful way of working.

    Posted Mar 10 2008, 11:15 AM by GlenChambers with no comments
    Filed under: