Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
ASanchezC1
Advisor
Advisor

Our recent Webinar talked about best practice and recommendations to take full advantage of the SAP Cloud Application Studio (SDK). Nowadays, the SDK is mostly used by partners for SAP Hybris Cloud for Customer and SAP Business ByDesign extensions and from Customers as well: We have more than 3000 add-ons running on productive customers. Great achievement!


Let me summarize first some basic - but important - messages given about the SAP Cloud Applications Studio to its users which coincides with my guidance to ISV partners. Also, you will find recommendations on Life Cycle Management out of incidents created by partners.


Hence, we encourage all Studio user to take advantage on existing documentation on Lifecycle Management at help.sap.com or in other relevant blogs such as Tips and FAQs; Deployment and Landscape Basics. If documentation does not help, you can create a ticket on PDI (pre-requisites to create an incident on PDI).




  1. Basic recommendation about the lifecycle and 3 tenant landscape


Why? In some cases, Partners/Customers start the extension development using a 2 tenant (test, production) approach. The general recommendation is to use a 3 tenant landscape with the following set-up:




  • One development tenant (additional tenant, minimal configuration only for developers).

  • One test tenant (fully integrated and primary test system)

  • One production tenant (fully integrated for production use)


 



 

2.  Customer Specific Solutions, Solution Templates and Multiple Customer Solutions.

Details can be found in existing Studio help documentation but understanding the concept will assure a better developer choice and you will understand each option limitation and guidelines.




  • Solution Template: Allows you to organize common development content to reuse for customer-specific solutions. It also enables you to rapidly start the development of customer-specific solutions, for example, for a specific industry. When the design is not ready, and you think the code may be reusable, solution templates allow you to continue changing the solution. BUT consider the following:

    • The Solution template itself cannot be deployed to the production tenant (it is not an independent solution). It needs to be imported into a customer specific solution before it can be used.

    • Double maintenance: Once a Customer specific solution is created from a solution template, further changes must be manually applied to keep them in sync.

    • Admin mode cannot be switched on for solution templates and hence the creation of Analytics content and mashups is not supported.



  • Multiple Customer Solution: This is approval based option, still for very good partner management reasons. Please contact your SAP PSA (Partner Service Advisor) for details.


 

3. Highlighted features on the lifecycle and what developers should consider to do


    • Administration Tasks: Let’s remind some of them: Delete (Deletes the created customer-specific solutions. Solutions in Production tenant cannot be deleted. Instead we encourage Partners to switch off the solution by deselecting it in scoping in the production tenant); Switch Customer (Relevant only for the Partner development tenant) If the customer specific solutions are developed for different customers, the developer needs to ensure that the right customer switch takes place before development starts. The assigned customer is always shown next to the My Solutions.

    • Implementation ManagerActivation and Assemble, an automatically generated email is triggered to the user responsible for the add-on (Developers need the email id maintained in the solution properties) Download a Copy: Create a copy of the Solution in the same tenant to continue developing in order to try out different scenarios without disrupting the original solution. There is no merge back of the content of the copy to the original solution. It always creates a new solution copying all the objects to the new name



 

4. Recommendations for most common mistakes.



      • Upgrade times. What to do during upgrade times when test and production tenants are not on the same release? You cannot upload a solution to a lower release. Ex. Solution cannot be downloaded from 1611 test tenant and uploaded to a 1608 production tenant.

        • Then: Complete your development, testing and downloading of the solution before Test tenant gets upgraded. Do not plan any major feature deployment until both Test and Production tenants are upgraded.









      • Testing in a 2-tier environment. A customer has only one test and one production tenant, and the test is used as development tenant. In this case the patch and original solution both will be present on the same test tenant.

        • Then: After creating a patch, the patch should be imported into the original on the same test tenant where it was developed and then it can be tested. After successful tests it can be uploaded to the production tenant.



      • Split activate, assemble and download processes. Some Studio errors during the activate, assemble and download LM processes occur because developers use foreground lifecycle processes leading to time-out on the Studio depending on the size of the solution.

        • Then: Apply the new features where activate, assemble and download are split as background processes will not cause a time-out in the SDK.  On completion of the process an email will be sent about the success or failure (to the email id provided when a new solution has to be created).



      • Version History. When upload fails because Lifecycle Management processes i.e. activate, assemble, create patch and developers do not know the status of the task triggered and hence creates an incident.

        • Then: Use the Version History tab in the Implementation Manager to view the logs and any informativemessages shown before creating an incident.



      • Download a Copy. IF using ‘Download a Copy’ in the Implementation Manager to download the solution, upload this copy to the target tenant. This creates a new solution in the target.

        • Thus: Typically this feature should be used only to create a copy of the Solution in the same tenant to continue developing in order to try out different scenarios without disrupting the original solution. The label ‘Download a copy’ is changed to ‘Download a copy as a new solution’ from release 1608 onwards



      • Deletion Process. At the time Delete solution fails. In some cases, the developer triggers the solution deletion and the process fails but the deletion failure message is unnoticed by the developer and later triggers a deployment of the same solution. The deployment fails due to the inconsistency state of the failed solution deletion.

        • Thus: Developers should check the error message shown in Studio to take corrective actions before creating an incident.






 

Last but not least, we acknowledge a close collaboration between Developers is wished at both sides (SDK team of developers and users). We aim for this as well. We encourage you to keep the dialog as we set on the format you may prefer and share with us feedback on missing features ( why not to use the space for Cloud Applications Studio at idea place for SAP ByD)