Skip to Content

Very often, we get customer requests for functionality not provided by the native SAP Design Studio components. To address them, we have developed a suite of Custom Add-on components. But creating components using the SDK, is a very involved, time-consuming process. For requirements that call for a quick and easy solution, we have what we call, the HTML and Script Boxes. Michael Howles has a post on the same topic – http://scn.sap.com/community/businessobjects-design-studio/blog/2013/12/17/ds-12-sdk–rapid-prototyping-addon-htmljs-templating. So here, we will focus on some common applications of these simple yet versatile components.

The HTML Box enables you to add HTML elements to a SAP Design Studio dashboard. Install the component and drag & drop it at the desired spot on the canvas.

Html Box Drag and Drop.PNG

In the Additional Properties of the component, in the ‘Html Code’ area, enter the desired code and click on the ‘Submit’ button. On running the application, you can see the video on your dashboard.

Video code.PNG

Functionality achieved with just 2 lines of HTML Code ! With this, you can include video (MP4, WebM, Ogg formats) using the HTML5 video tag and audio (MP3, Ogg, WAV formats) using the HTML5 audio tag.

Another commonly asked feature is to add custom shapes to the dashboard. This can be done using the HTML Box and SVG tags. This is the code for the star.

Code for star shape.PNG

Custom shapes using SVG.PNG

The Script Box is an invisible custom component that accepts JavaScript code. Let’s add some functionality to the custom shapes using this. How about a dynamic conditional alert ? Here, we have a Crosstab showing Actual and Expected values. Let’s display a red or green alert signal based on how the Actual compares to the Expected. Add a Script Box to the canvas.

Script Box Drag and drop.PNG

The Element ID of the cells in the Crosstab can be found using the Developer’s tool, on any browser (F12 Key).

new ele id.PNG

The IDs found using the tool are :

‘Actual’ value in the Crosstab – __cell2_contentDiv

‘Expected’ value –  __cell3_contentDiv

Alert circle created using the HTML Box – alertcircle

Text inside the Alert circle – txtval

Now that you we have all the Element IDs, enter the following JavaScript code in the Script Box and click on ‘Submit’ :

var act=document.getElementById(‘__cell2_contentDiv’);

var exp=document.getElementById(‘__cell3_contentDiv’);

var al=document.getElementById(‘alertcircle’);

var txt=document.getElementById(‘txtval’);

if(act.innerHTML>exp.innerHTML)

{

al.setAttribute(“fill”,”green”);

txt.innerHTML=act.innerHTML;

}

else

{

al.setAttribute(“fill”,”red”);

txt.innerHTML=act.innerHTML;

}

JS Box Code.PNG

On running the application, you can see the alert displayed based on the Actual / Expected values.

Green alert Circle.PNG

Red alert Circle.PNG

Wasn’t that really easy ?  Wondered how you could incorporate an SAP XCelsius dashboard into SAP Design Studio ? Well, you can achieve that as well, using these components. The possibilities are endless !

Source: http://visualbi.com/blogs/design-studio/customize-sap-design-studio-using-html-and-script-boxes/

To report this post you need to login first.

12 Comments

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

  1. Mustafa Bensan

    Hi Keerthana,

    Thanks for sharing.  I wanted to provide some comments by way of constructive feedback:

    1)  Generic HTML and JavaScript SDK components

    Careful consideration should be given to embedding HTML and JavaScript directly in Design Studio apps via generic SDK components such as the ones you have mentioned.  I think Mike Howles‘ example of the Design Studio 1.2 SDK – Rapid Prototyping Addon HTML/JS Templating was mainly intended as a tool to accelerate development proof-of-concepts which would subsequently be converted to full SDK components.

    I think adding HTML and JavaScript directly has the risk of increasing the maintenance complexity and potentially making it more difficult to debug issues.  One reason given for using these generic components is the involved and time-consuming process for developing SDK components.  The main effort with SDK components involves coding the HTML, JavaScript and CSS.  Since this is required for the generic SDK components, it’s probably not that much of an extra effort to simply wrap the HTML/JavaScript in a full-fledged, purpose-built SDK component anyway.  These components would then be easier to reuse and maintain rather than having to copy and paste;

    2)  Custom Shapes

    I agree that custom shapes are certainly a popular request.  I think this is all the more reason to create them as full SDK components to take advantage of standardised manipulation via properties and BIAL script contributions.  Again, in my opinion, encoding SVG directly in a generic HTML component presents the risk of added complexity of maintenance;

    3)  Script Box – Manipulation of DOM Elements

    The ability to inject custom JavaScript via a generic component such as the Script Box requires caution to avoid inappropriate manipulations that may not be supported.  If I understand the above Script Box example correctly, the free-form JavaScript is directly manipulating DOM elements of other components.  As I recall from the SDK Workshop I attended in Walldorf earlier this year, such DOM manipulations were expressly discouraged;

    4)  Embedding Xcelsius Dashboards in Design Studio

    I read about this scenario every so often.  The two main reasons given are:

    (a) To take advantage of Xcelsius components that do not yet exist in Design Studio;

    (b) To facilitate an easier “transition” from Xcelsius (Dashboards) to Design Studio.

    In my opinion, the above scenarios simply perpetuate the dependence on a legacy product (Xcelsius) because both scenarios would still require ongoing maintenance with Xcelsius.

    In scenario (a), why not just create a new Design Studio SDK component?  Yes, perhaps it requires more effort initially compared to embedding an Xcelsius component but I think it makes for a cleaner solution that is easier to maintain in the long run.  Also, mixing embedded Xcelsius components with other standard and SDK components has the potential to negatively impact the user experience due to a hybrid look and feel of combining different technologies, since the same CSS styling would not be readily applicable to the Flash-based Xcelsius components;

    In scenario (b), I question why one would want to embed an entire Xcelsius Dashboard within a Design Studio application.  I would say if Design Studio doesn’t yet meet the requirements of a customer, then just continue to use the Xcelsius dashboards as is, independently to Design Studio and consider Design Studio for new dashboards if appropriate.

    Anyway, the above are my opinions only for purposes of discussion.  Perhaps others would like to comment as well.

    Regards,

    Mustafa.

    (0) 
    1. Mike Howles

      1)  Generic HTML and JavaScript SDK components

      Careful consideration should be given to embedding HTML and JavaScript directly in Design Studio apps via generic SDK components such as the ones you have mentioned.  I think Mike Howles‘ example of the Design Studio 1.2 SDK – Rapid Prototyping Addon HTML/JS Templating was mainly intended as a tool to accelerate development proof-of-concepts which would subsequently be converted to full SDK components.

      I think adding HTML and JavaScript directly has the risk of increasing the maintenance complexity and potentially making it more difficult to debug issues.  One reason given for using these generic components is the involved and time-consuming process for developing SDK components.  The main effort with SDK components involves coding the HTML, JavaScript and CSS.  Since this is required for the generic SDK components, it’s probably not that much of an extra effort to simply wrap the HTML/JavaScript in a full-fledged, purpose-built SDK component anyway.  These components would then be easier to reuse and maintain rather than having to copy and paste;

      Hey Mustafa, we sure are good at reading one another’s minds.  🙂

      I completely agree that HTML/JS injection is a dangerous path to go down, and not recommended for the casual designer layman. That being said, it sure continues to be a handy utility that for those of us who know what we are doing can use, and it’s a hard habit to break using 😀 .  I continue to go back and forth on removing it, but I think the benefit outweighs the risk and it’s not supported by SAP or me so it’s just a cowboy coder point for now.  Besides, we technically had this in BEx WAD so there’s even an argument to be had there for its legitimacy, I suppose!

      (0) 
  2. Karol Kalisz

    Hi,

    at firrst, for me the examples are nice to see hat is possible. And also the generic HTML / JS is also nice to make rapid prototyping.

    but then on second, I would be carefully as this generic component is a kind of open SDK on  top of the official SDK – and should really be restricted to prototyping.

    now, I see on this follwoing points which should give to think about.

    Componentization

    SAP provides the SDK for extensions in design studio which have a componentization concept in background, you write it once and then you deploy it in different applications. in the free HTML/JS case it is bound to the application – so on every application you have a copy.

    Self-Containement

    From SAP side the SDK can only assure that the SDK API stays stable, but not the rendered HTML of the application. This means you can very easily break such HTML/JS based implementation with SP or other upgrade – even by introduction of new functionality in the same app or moving the components. SDK component must not touch other components – as this is introcing dependencies whcih cannot be approved and maintained.

    Maintenance

    no version control, the code works only in the app and you cannot really maintain it in long term

    Performace

    perhaps not so critical on small content, but when this scale out, you hava a lot of traffic just because all the content is send with every app and cannot be cached in the browser.

    Comment on the JS

    in the JS example, I do not belive the IDs used will be too stable..

         var act=document.getElementById(‘__cell2_contentDiv’);

    This ID is very not promissing.

    Mustafa / Script Box – Manipulation of DOM Elements

    this is correct, manipulations of other components via script is not what SDK intended to do – SAP cannot block this technically, but SAP cannot support this as well.

    Michael / WAD

    […] Besides, we technically had this in BEx WAD so there’s even an argument to be had there for its legitimacy, I suppose! […]

    This is true, it was technically possible in WAD (but released was only custom Exit Item with the purpose to have self contained HTML block in the rendering) and not free HTML modification of delivered standard. We all know customers made this, but this is exactly at the same support gray area as the modifications of delivered components – it may work, but latest if this does not work support is not there from SAP.


    Time to Code?

    Getting out of any prototyping and smaller examples. is this really so more effort to make an SDK component? Yesterday, after my work I had 2 hours – and this was just enough to code the Design Studio SDK: Data Bound Range Slider, including compilation, local test and release to GITHUB. Of course oyu need to code some components to have a bit of routine, but in non-prototyping area this sould not be a big issue.

    Finally, I find this extension and also the one from Michael as a good way to make prototyping, but please do not make this too extensively…

    Anyway, thanks Keerthana for bringing this points for discussion, I think we can find some more information on the reasoning to improve the existing SDK – eg. what is the part which is making the SDK overhead, do you have any ideas how we can imporve there?

    (0) 
    1. Mike Howles

      Time to Code?

      Getting out of any prototyping and smaller examples. is this really so more effort to make an SDK component?

      I agree, however in many organizations, I’d imagine that doing a nightly/weekly/even monthly MDAS APS Restart for one’s newest SDK iteration to take effect on the BI Platform for instance is not possible.  JS/HTML injection kind of gets around this as a stop-gap.  I still don’t like that, but it addresses the scenario.

      (0) 
      1. Karol Kalisz

        Hi Michael, all,

        dow it mean you always develop on the platform? actually I am making this locally in the local mode (mainly under the assumption SDK is abstracting the platform).

        (0) 
        1. Mike Howles

          Good point, and I’m playing devil’s advocate mostly, and to maybe push for an easier way to refresh newer iterations of SDK plugins that do not involve restarting an MDAS APS 😉

          (0) 
  3. Keerthana Ramesh Post author

    Hi all,

    Thanks for your valuable feedback and suggestions.

    This is one thing we built when we started our development with the Design Studio 1.2 SDK and now it is more than a year old to show its face on SCN.


    The story behind this component is, we were getting a lot of new component requests and ideas everyday.Of those, few of them are very basic ones which does not require a lot of JS/HTML knowledge. So we split the bucket into two. One with complexity and business value and the other, simple ones (like the circle rectangle etc.). Building those simple components does not require a lot of work, but packaging them and making them into a suite takes twice the time than creating these simple components. It involves a lot of work.


    We can also build a component with different shapes, but if they need a shape that is not there in the component, we would have to go through the packaging process all over again. So we thought self service would be a best option for simple stuff.


    Even we don’t suggest using this for complex situations. Seriously when it comes to Javascript, it can dismantle the entire dashboard. For example document.write(“Hello”); will delete the entire dashboard and welcome the user with a simple text “Hello”. But JS when used carefully, can do wonders.


    And we have also planned to involve some advanced validations which also checks for syntax errors and restricts the user from not using the dangerous script methods such as the document.write methods etc.


    Adding to Mike’s point, each time we install a new component or a newer version of the existing component, we need to restart the APS module allocated for Design Studio. This scenario gets complex when the system has a single APS which is not split for Design Studio. All the services will be down for a few minutes till the server restarts.


    Mustafa,

    We are building all the Xcelsius components for Design Studio as well. We are filling the gaps that Design Studio currently has.But this was just a suggestion that when you want to show multiple Xcelsius dashboards this will come in handy.


    (0) 
      1. Mustafa Bensan

        Hi Jim,

        That’s a great link showing the creative effects that can be achieved for shape generation with pure CSS and the standard Text Box component, thereby eliminating the risks mentioned in the above comments and the need for SDK development work.  Presumably, if necessary, SVG could also be embedded directly in the CSS?

        Regards,

        Mustafa.

        (0) 
          1. mohd fahad

            Hi Michael,

            thanks for introducing this exciting tool. I tried to save the file. “Saved to local storage” – But i am unable to track down o my system. Any idea where does the file get saved?

            -Fahad

            (0) 

Leave a Reply