Before get into details about the subject i want to clarify what i do understand as "Universal" and what is the scope of the information shared here:
Normally the Visual Composer models are made by Business Process Experts which want to prepare reports and dashboards for executives and stakeholders, however the process is wide open and other scenarios appears, for this reason I want to share with you my concept of "universal model"
An "universal model" is that Visual Composer applications that can be deployed in any Portal and consumed with a minimal adjusting effort, i.e: you've created a report that interact with an ERP Logistics area providing with a Sales report and it can be used by your current customer or by any other customer with the same backend/portal version.
The most popular of the universal models is the xApps Analytics and some applications used by SAP Business by Design, which has been created by a development team and used by several landscapes around the SAP ecosystem.
In this blog I want to give you a hint about how to make your Visual Composer Model Universal, that means you will be able to transport it to your Quality Assurance and Productive Portal, as well as re-use it in any other project that you have in the future, of course before do this, please be aware of Intellectual Properties topics.
Let's do it:
During the design time of your Visual Composer Model, you have to identify the dataservices, which are those data repositories where you will extract the information or interact with the backend system, normally we use Web Services, BAPI's in SAP System, BI Queries, JDBC Queries, all of them linked to a backend system that exist in your NetWeaver Portal.
There is the single point of failure (SPOF) that you have to avoid making this model universal, this SPOF is the system alias. Let me explain it to you:
Normally your Development Portal with system ID (EPD) is connected to Development backend systems, (like DEV for SAP ERP, BID for BI CRD for CRM, etc) and the system administrator use the same system ID to create the system alias in the Portal, so while you are creating a model you normally use those aliases to retrieve the dataservices from the backend.
This is the point that we should change to make our model universal, in a single way: just use common additional alias to the backend
I want to illustrate this with an example:
In this case the backend system ID is ALA and I just add SAPERP as an additional alias. This common alias is the one that I need to use during the design phase:
Hence if you transport / migrate this model to the NetWeaver Portal used for QA or to another NetWeaver portal, the only thing that you have to adjust is to add this alias to the desired backend system, and there you will have the model / iView working without any problem.
It will work for simple or complex models, of course you have to prepare the documentation to indicate the pre-requisites like add the "ABCD" alias to the backend system in your portal before import the package / model.
For complex models with several dataservices, be sure that you select common aliases for all the systems involved.
I hope you find this information useful, and I'm sure that you will not have to deal with transport issues any longer.
3 Comments
