SAP HANA Transport Best Practices

[Former Member]

Hi all,

Need some collaborative thinking here. We are currently starting to transport our HANA views to target Q and P systems as per usual build process. Id like to collect some feedback on best practices in the transport area as I can find little content on this. If anyone has links, documents please share. A useful one I have found is here: Export and Import feature in HANA Studio -  http://scn.sap.com/docs/DOC-26381

As I understand it delivery units are the method of transport which authenticate the import/export process. EG as per practice you should assign packages to delivery units and then all package content is exported and imported into the target system when a delivery unit is requested for export/import - similar to BW transports.

But what about global package areas? If HANA is meant to eventually supply data to all SAP applications then surely most content will be global and should be organisaed as such. For Example, we are making our models as global as possible and have organised content in 3 distinct package areas:

1) Master Data - holding all global reuseable master data attribute views

2) Foundations - holding all global subject matter attribute and analytic views

3) Applications - holding all project/application specific attribute, analytic, calculation views.

*Each of these areas can be further organised into subpackages (EG in master data package we have a customer, material, distribution channel packages which hold relevant models and make it easier to locate specific master data.

Based on this organisation delivery units only make sense for the last option. EG a delivery unit is assigned to project team. Then when they are ready to transport they assign all the packages to the delivery unit for transport. This works in this last option because all build is owned by the project and thus should be managed appropriately (EG a transport of the package should not be requested if development of an object is not finalised). We get around this by enforcing a role for developers to only copy models into the above areas once they have been unit tested and approved in a special development area.

However how can we ensure that the global areas (Most import views and content) can be safely transported without risk to the target system integrity? As discussed above if I create a new build under the master data package I have to transport the entire package content. But I only have visibility and knowledge of my model and no one elses. How do I know that my request isnt going to allow for the possibility that one of the other modelers has performed a modification on another view within this area to be transported. Short answer is I dont.

So my question is how to we ensure the integrity of transports and the target system? I know you can export import individual objects to target with the developer mode but this says to be used in extreme situations. To me this isnt an extreme situation but common practice. Can HANA provide a authenticate import/export process which is object specific?

Pleased to hear thoughts.

Kind regards,

Danielle

[Former Member]

Hi Experts,

Can someone explain the limitations & benefits of the use of CTS+ and DU method in the transportation of HANA contents?

And, Does the integration of CTS+ in HANA involves greater costs?

Regards,

Gopal

[Former Member]

Hi Danielle,

There's a webinar event on October 21st "SAP: A CIOs Perspective" during which the CIO of one of the first retail businesses to ever implement SAP HANA will be sharing his insights and experiences.

I know this doesn't specifically answer your bolded question, but there will be a Q&A session at the end of the webinar during which you will be able to ask the host a variety of questions. If anyone else is interested as well, he'll be talking about an array of other decisions he had to make when they implemented SAP and what he thinks about those decisions today.

Here's the registration link.

Best,

Amanda

[Former Member]

Hi Danielle,

since SPS 8 you can record object changes and transport only the changed object through the DU with one of the transport possibilities like CTS+.

Please take a look at SAP HANA Application Lifecycle Management (HALM) and take a look especially at slide 33.

Thanks & Kind Regards

Klaus Steinbach

[Former Member]

Hi all,

The real problem is actually the advertised principle of "re-usability" of HANA views (AT, AN views) across the landscape, so that you only need to make the change once and all the models which build upon it, so it will update everything at the same time. No more "out of date models".

The problem of course is that this small change can have large implications as we don't copy models between packages.

The other aspect to this, is the granularity of packages. Even when selecting a very granular approach of  a package to reduce the impact of changes to other packages, as you have "re-usability" of views, it still works across packages and they are not really isolated. I personally prefer to move whole "sections/areas" in one go, which work together. Otherwise dependencies will become very hard to manage. The list will become longer and longer.

The solution for each business is to find the balance between governance (ensuring proper testing, dependency docs, signoff process etc) and change requests /development work. More testing is needed for development work and maybe a little less governance checks to enable rapid application development.

It would be a nice idea for a new feature of a reverse "where used", lets call it "builds on", which can check the whole tree of dependencies of a top level calculation view (currently manual documentation) all the way down to the tables. Still that doesn't resolve interdependency ...

My 2 pence, maybe there will be a clever technical solution to the problem in future.

Kind Regards,

Denis

[justin_molenaur2]

Excellent insight Denis. We are working through some similar exercises on my current engagement as we start moving enhancements to existing content to target systems.

I am just curious as to what you have observed with regard to the dependencies you mention in you first two paragraphs. The specific example I have is that when you modify an AT view, it redeploys any analytic view that consumes it, the calculation views that may consume the analytical view, and then any stored procedures that use any of these objects. Quite a cascading effect and does not bode well for stored procedures.

Another question is how you are actually performing the migrations, at a delivery unit level or developer mode just grabbing individual models? File system import or CTS+?

Regards,

Justin

[Former Member]

Hi Justin,

Stored Procedures are very fragile, any sort of incompatibilty which it may have been able to auto-resolve, ends up to be an error. I am avoiding them as much as possible. Any SQLscript which is written manually can't take the benefit of using the cascading updates. You will need to write a dependency document to check all dependant stored procedures again after underlying changes.

I personally use delivery units, but we are moving to a CTS+ model, as the SAP basis/transport experts are more familiar using this. Life Cycle Management app (XS Engine) is also a choice, but if you can still go with CTS+.

Tip: Developer mode I only use to take a quick backup, of a model I am working on in the development area. So if you have a reasonably well working model, in your development area and need to make quite a drastic change, where you may end up with worse performance, it's good to keep a backup.

Kind Regards,

Denis

[justin_molenaur2]

Thanks for that.

Agree with the CTS+ approach for sure, it's more natural for most existing SAP customers.

So if you take the approach to use delivery units, how are you generally organizing your packages? In situations where some of you models have shared components in other packages, are you grabbing those other packages as well?

Furthermore, when you are using delivery units with CTS+, are you employing any strategy (or have you seen anything) where developers are using a "development" package and only moving objects into the "root" when its ready to move? Something that has been considered at my current client is to move the entire root package every time in a delivery unit. Until the point that your new development is 100% ready to migrate, it is kept outside of the root package, and at some given interval (say weekly), the root package is migrated in total to QA and/or Prod.

I know this is an all new approach with migration, so appreciate your feedback.

Regards,

Justin

[former_member184969]

The 'Builds on ' as described by Denis actually exists in the HANA Live browser ! You can visualize the whole dependancy chain of any (even custom) view down to the table.

Usefull !

A pity it's not incorporated in the HANA Studio, however.

Regards

Stephane

[Former Member]

HI Justin,

I wanted to see what you experience was in handling the development package and root package separately. How did you handle moving content that has been unit tested in the development package to root package. When a better version of the view is available in the development package, did you delete the exiting view in the root and copy it over? or did you manually make changes to the view in the root package?

Thanks,

Doniv

[justin_molenaur2]

I had a very similar question at a recent SAP CodeJam. It seems that there is no current best practice recommendation in general, its kind of wide open for you to define.

After some thought, I came up with a couple ideas based on scenarios.

1) Designing content for an analytics-centric HANA installation - this is where you are more or less trying to create a DW or DataMart with reusable components. In my head, I would approach this by organizing the packages by functional area and component type (eg, FI Attribute views, MM attribute views, FI Analytic views). In this way, you can present a library of sorts (BW speak InfoAreas) where you can minimize the risk by only moving small numbers of actual models with a package level import.

In this scenario, there can be constantly evolving changes, typical of any DW.

2) Designing applications for non DW/DataMart scenarios - this is where maybe one common shared package for all true globally reusable objects might make sense. Aside from that, all project related artifacts can be moved together.

Here (at least in my mind), once the project is completed, there may be comparatively less iterations once it goes live when compared to the DW scenario.

Hope this helps, I struggled with the same questions myself!

Regards,

Justin

[rama_shankar3]

Justin,

  Thanks.

Rama Shankar

[Vasanth_SAP]

Hi,

HANA also supports the traditional Change and Transport System ( SAP CTS+ ). With this the transports between the system can be performed using transport requests concept.  The developer can add to the transport request what part of the development work he wants to transport.

Also with Solution Manager integrated into the landscape this can be performed in a controlled way like the traditional NetWeaver Transport Management process.

Have you explored this option?

Regards,

Vasanth

[Former Member]

Hi Vasanth,

These seem like very viable options I was not yet aware of could be used to authenticate transport at object level rather than package level delivery unit method. If this is teh case where can I read more about these process and how we can implement them most effiencient on client site?

Our current work around is to allow developer to export delivery units (EG acting as the relase like in bW that takes a snapshot of the development) and then the business has a process to import the specific objects in the export rather than importing the entire export. Any other way of doing this is extremely interesting to me.

Kind regards,

Danielle

[former_member206725]

Hi Danielle,

I was just wondering if you have progressed this issue further.

I am very interested in your findings on the best method to transport HANA configuration.

Kind regards,

Renato

[joseph_gonzales]

Hello Danielle:

On the SAP Netweaver How to Guide Center:

http://www.sdn.sap.com/irj/sdn/howtoguides

I found this very detailed document called:

How To... Configure SAP HANA for CTS.

This explains in great detail how to use CTS+ with HANA Devivery Units.

Hope you find it useful,

Regards,

Joe Gonzales

856 912 1136