Skip to Content

We got a basic understanding of what is Cloud Foundry in the first blog post.

Did SAP just grabbed Cloud Foundry and put its logo on it? Of course not. We have a very powerful database called HANA and a whole set of tools were already in place and being used by devs out there. This was about combining existing capabilities and porting the already powerful onto the more scalable and multi-cloudable. Some of the Cloud Foundry characteristics were not adopted and the proper SAP adaptations were performed.

Let’s drop the buzzwords and understand this mashup:

What are Multi Target Applications?

This sounds like one of the (many) cases of fancy names for something simple. You’ll tell me if this applies later…

Typically, an enterprise application will access the database and have coding to add business logics to the data (or share data to another system, or nag a user for action, or insert more data, etc). This application is normally defined by somebody, coded and unit tested by someone (else), validated as a part of a bigger picture and finally moved to a productive environment. We call this lifecycle, right?

More technically, we have a user interface, we have some logics and then we have the database.

The some logics part is not as innocent: A fullstack coder friend of mine used to talk about “the backend of the frontend” and “the backend at the back”. In other words, you could even have business logics in two different places: the coding feeding the UI and the logics embedded in the database modelling. Different components (layers), same lifecycle:

 

In our new architecture, each of these layers can be mapped to a different box in the XS Advanced architecture diagram (presentation layer at UI5, backend logics to Node.js or Java and the modelling and database at the base).

I’ll let you add the arrows mentally for this one:

First, let us respond to the original question. A Multi Target Application is an application whose runtimes are provided by the different boxes or components but only serves a business purpose if those components are held together through its lifecycle.

(I hope you can produce your own definition and tell me if the name is just fancy)

For example, you will develop a piece in UI5, another piece in Node.js and a CDS view that taps the database. Each of these could even be created by different developers or executed separately but they would make no sense unless they are treated as a single business application on its way to the productive environment.

 Let’s go deeper into the technical level…

In the XS Classic approach, each of these “boxes” would have run all of the different applications in copies of the same (JavaScript) virtual machine, against a connection to a schema in the database administered by the applications. That is, a single operating system process eventually catered for all of the runtime needs of each of our different coding masterpieces. You could sometimes see the XS Engine process sweating…

The monolithic process serving all VMs

In the new approach, for the logics piece in Java or Node.js, a “copy” of the box (call it runtime) is created and bound to a specific application. Even the database binds a dedicated instance of itself to a single application in the shape of a container (note that I am not using the word “copy” for the database… that would be huge).

This way, our business application will get its own piece of Node.js runtime with everything it needs to execute its code as a separate operating system process. Something more like this:

Those copies of the runtime are called “microservices“… the name is not as fancy, but I can assure you it’s a bit tricky.

We can take a deeper look into this architecture and its implementation in the next blog post

Let’s stay in touch on  or on LinkedIn !

To report this post you need to login first.

8 Comments

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

  1. Matt Harding

    Hi Lucia,

    This is a much needed blog series you’ve started. While your content is good for me, I know of people developing mostly Calculation Views (some are not traditional programmers) who don’t understand why they need to move to WebIDE or why their very simple XS Classic package view of the world without complex security is not going to be supported in the distant future; and how this all fits in with BI Explorer in terms of migration. Hence would be great to have the dummy guide cover these “developers” also if you get a chance in the future. I’ve attempted to help, but from all respects, it looks like their simple approach to reporting will just get a lot more difficult for minimal benefits.

    A big ask, but just in case you go there…

    Cheers,

    Matt

    (3) 
    1. Lucia Subatin Post author

      Hi, Matt!

      Thanks for the input… I was not planning on going there but it is a very good question. I do not think I’m the right person to respond as I have not used Web IDE as intensively as HANA Studio for Calculation Views.

      There are some visible perks that I would have appreciated in HANA Studio that are now in Web IDE. I can quickly think of these examples now and of course they are my own personal impressions, so there is surely more to this.

      • The  new currency or unit of measure conversion would have saved me a lot of time in both development and performance measurements back when i was developing these for productive use. I did a little tutorial on this (don’t be misguided by the original URL, of course sql script views are still long gone): https://www.sap.com/developer/tutorials/xsa-sqlscript-cube.html
      • The MINUS and INTERSECT nodes were also a pleasant surprise for many scenarios I had to (poorly) cover
      • Noticed some refactoring and renaming that I would have also appreciated among the list of life-saving features (like when the “Show Lineage” feature suddenly appeared on HANA Studio)
      • And the debugger!!

      Definitely a good question and i’m sorry my answer is so limited. I understand there are probably many folks out there wondering this as you say… Hopefully some angels in the community can chime in

      Cheers,

      Lucía.

       

       

      (1) 
      1. Matt Harding

        Thanks Lucia.  I didn’t think you were going there, but wanted to point out that this is a really important dummy guide that is really required.  Plus helps a lot getting a response from Rich!

        BTW – The other challenge is they are on SP11 with no real push to go to HANA 2.0 (even though this is HEC) as the length of support of HANA 2.0 SP is actually less than HANA 1.0 oddly enough, so the features you discuss aren’t quite up to par in that release. That said, really appreciate the pluses you mention.

        Cheers,

        Matt

        (1) 
    2. Rich Heilman

      Hey Matt,

       

      Yes, it is more complicated, especially around the security model.  Those users who are used to only creating calc views in XSC might initially be turned off by the new environment.   The actual object will migrate very nicely, without much manually manipulation.  As far as exposing to BI tools, we can use the .hdbsysbicsynonym to expose our calc view from our container and make it look like it is in the _SYS_BIC schema, which will make it visible to the BI tools.   As for minimal benefits, we would definitely not say the benefits are minimal.  With the new concepts, you get better import/activation, better security with the container technical user, better management of both new development and fixes/patches at the same time having the integration with Git, etc.

       

      Cheers,

      Rich Heilman

      (3) 
      1. Matt Harding

        Thanks Rich.

        As a developer type, I can appreciate many of the benefits and have been encouraging them to migrate ASAP for quite some time.  But for people working in a HANA Live (read-only data replication) environment directly creating Calculation Views in production; these benefits actually come across more as negative, but I do get your point.

        And the synonym sounds perfect to ease the transition, so that’s the biggest concern I had for ensuring end users who have created enormous Excel analytic spreadsheets or Lumira reports from published HANA views would not break.

        Anyway, maybe this is just another reason to wait for an upgrade to S4/HANA and this customer can just survive on SAP’s typical very long tail of supporting deprecated functionality!

        Good times!

        Cheers,

        Matt

        (1) 
  2. Shyam Uthaman

    ​Hi,

    I created a new project in my XSA. Now I am lost on how I can bring the Packages and views I had built using HANA studio.

    In the database explorer, I could see the schemas and tables but I can’t find the views anywhere.

    Please Help. I’ve gone through the documentation but couldn’t find any examples where an existing view was brought into the XSA screen.

    Also, can you please advice if there is a conversion process from calculation views to hdbcalculation views? I need to leverage the new null value handling feature for my existing views.

    Regards,

    Shyam

     

    (0) 
    1. Lucia Subatin Post author

      Hi, Shyam,

      Here’s the documentation to migrate the views and other objects: https://help.sap.com/viewer/58d81eb4c9bc4899ba972c9fe7a1a115/2.0.02/en-US/2aa5aa246a704e199cd06ca5c84d1155.html 

      If you haven’t enrolled already, this open SAP will also cover some migration aspects (and XSA dev in general): https://open.sap.com/courses/hana6  

      If you want to see the plain schema, you can log in to the DB from the DB explorer just like you did with Studio:

      If you want to access the data in those tables from your db module, this should help (the cross-container piece) : https://www.sap.com/developer/tutorials/xsa-create-user-provided-anonymous-service.html

      Cheers,

      Lucia.

      (0) 

Leave a Reply