Skip to Content

SAP Business Objects Planning and Consolidation version for Netweaver leverages Netweaver infrastructure and we can use the transport mechanism to promote configuration through the system landscape. In this blog we will talk about some tips regarding using the transports in BPC.

The first question that is often asked is whether there is any documentation available that explains how this transport mechanism works and how one is supposed to use it in the projects. Let us answer that first. A very useful document about transports is available in the Operations Guide on ServiceMarketPlace.  Section 5.1 in this guide is dedicated to transports and this is useful in understanding how the transport mechanism operates and how we should use it. It also explains what happens when certain objects types are transported.   For instance in case of TLOGO object type ‘TEAM’ – what really happens is… “Teams that are created in development are never transported. User assignments for teams are not transported because users are configured in each environment and typically, the users accessing the development system would not be the same users to access the production system. Therefore, this TLOGO object is only useful if the team names are the same in development and production (created manually in each environment). Then the files for the team can be transported to the team in the target system. The team transport transports any conversion file or transformation files that are assigned to this team.”       

This document can also be accessed very easily from the SAP help portal help.sap.com. As shown below, you can go to the SAP Business Objects tab and navigate to Planning and Consolidation link and from there to ‘Installation, Upgrade, Master and Operations Guides’.

image

In addition to the information contained in that document, here are some more tips regarding transports:

  • Stay current with BPC NW notes related to transports.  Check notes under component – EPM-BPC-NW-TRA Transport
  • Make sure to check note 1415296 for procedural changes – BPC transport and installation troubleshooting summary. In case of any issues with the transports, you can refer to this note first.
    • This highlights a common issue – do not reference technical names of BPC objects in EDW  based BW models. 
  • Concerning the deletion of objects there is a different behavior between two major object types during the import of a transport into the target system. 
    • Table entries and Data Model objects (Application, Dimensions, Properties) will be deleted in target system when they are deleted in Development and the Appset is transported.  
    • Files such as script logic and Excel templates will only be updated.  So changes to these files will be transported.  Given it will only transport an update, the deletion of these files in DEV would not impact existing files in QA or PROD.  Please note the deletion of these files in target system will not cause any harm. 
  • Transporting specific objects within an object type is not supported – check this forum question for review of this topic… Re: Transport issue? Please note that SAP is planning to change this in a future release so specific objects within object types could be transported.  When this is released the framework will assist with dependencies. 
  • If you have a requirement for copying files, such as “Reports” and “Input Schedules” to other BPC systems, without the user having to do manual steps, then here is a very useful how-to guide to do so: http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/0096026f-7fc4-2c10-5c92-e75f4c13ca10
  • There are many SAP transport strategies.  Often times a QA or PROD system is built with every released transport from DEV.  My recommendation with BPC NW is to build systems with the last good transport.  If one were to send 6 transports to build a QA Appset I would only move the last good transport to build that same PROD Appset.  Of course there are other ways of handling this however I have not found any value and seen the potential for more headaches by using the policy of just moving all requests.  Also, since BPC transport framework can gather all APPSET objects, the fear of missing something can be alleviated.  In the future this strategy may not make the most sense when individual objects are transported as pieces could be missed.  Currently I do not see any issue – at least for the initial build. After going live, if the changes are always made in DEV and promoted up the landscape, then this strategy would still work well.

Now here are some things to avoid in BPC transports:

  • Do not change the data model in target systems.  A typical system landscape may contain DEV, QA and PROD instances.  If changes are made to objects in a target system the transports that originate from development can be broken (in most cases it will be).  Data model changes consist of objects like Appset, Application, Dimensions, Properties.  If a customer plans to maintain the data model in QA or PROD system that is a customer’s prerogative to do so -however that tantamounts to say that the customer has also decided to not use the transport framework since it will no longer import properly.  Things like reports, input schedules, data manager packages (non-data model related) can be changed in any instance. 
  • Do not change the structure or definition of BPC related data model objects in BW (RSA1).  This would include objects such as Appset (InfoArea), Application (lMultiprovider and InfoCube), Dimensions (InfoObjects), Properties (InfoObjects).  When you do this, subsequent transports will fail.  In some cases transports may fail and the only way to correct the issue is to delete an appset and re-import it.  If by any chance,  if you land in that situation, here is a blog that you may find useful to do so:   SAP BusinessObjects Planning and Consolidation version for Netweaver  – Deleting an  Appset
  • Do not be alarmed if the technical name of the InfoCube/Multiprovider changes between landscapes.  This is normal.  BPC does not transport technical names of cubes and the transport will work fine. If you are referring the technical names of the Infocube/multiprovider in any EDW based BW models, this may cause an issue. Hence as a general rule, please do not reference technical names of BPC generated objects in any EDW based BW models. Please note that the technical names of InfoObjects do not change as a result of a transport.    

These are some of the things that one should know to effectively use BPC transports in BPC7.xNW.

To report this post you need to login first.

2 Comments

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

  1. Gersh Voldman
    Hi Pravin,

    Very useful information, but we ran into one issue while following two SAP suggested strategies.

    First we made a copy of existing AppSet to distinguish Production Support from ongoing development. Naturally than new AppSet has a new name. All transport to QA, Production are going from that new (“Golden”)AppSet only.

    Now we changed a report in Development AppSet and wanted to promote it to QA for testing. We tried using How To Guide “Promote Reports …through your system landscape” recommended in this blog.

    The issue we ran into is that now those 2 AppSets have different names and this program asks only the source AppSet name. Even thought it says that everything is OK nothing is updated in the target system.

    We manually changed values of AppSet and folder in debug mode and it worked fine. Is it possible to update that program in such a way that it asks for a target AppSet ID?

    Thank you,
    Gersh Voldman

    (0) 

Leave a Reply