Skip to Content

Introduction

In this blog I would like to highlight a few of the most prominent features new features in SAP HANA SPS07 for developers building SAP HANA native applications.

If you want to review the general concepts of SAP HANA native applications and features which were delivered originally with SAP HANA 1.0 SPS05, I would suggest this blog:

http://scn.sap.com/community/developer-center/hana/blog/2012/11/29/sap-hana-extended-application-services

If you are also interested in the new features which were first delivered in SPS06, I would also recommend this blog:

http://scn.sap.com/community/developer-center/hana/blog/2013/07/01/sap-hana-sps6–various-new-developer-features

HANA Studio – Development Perspective

First, we have various improvements to the overall development tools experience in SAP HANA Studio.  Most important of those improvements is the removal of the dependency upon the HANA Client and REGI executable for the Studio to interact with the HANA Repository. This simplifies the update of the HANA Studio as the complete process can be done via update site now. Of greater interest to most developers will be the improvement in performance as now requests to the HANA Repository can be batched up. This improves performance, particularly in high network latency situations, but also improves activation accuracy when you are processing multiple objects which have dependencies.

For all the new enhancements to the Development Perspective main tools – and especially a demonstration of the improved speed of the repository interface thanks to the removal of REGI –  I would suggest this video.

The enhancements to the HANA Studio Development tools aren’t all infrastructure related.  We also see many usability improvements.

The Repository Browser, for instance, now has the ability to edit package details, it has a remove from client (allowing you to remove checked out files from the

local repository workspace), regenerate (forcing runtime regeneration without having to go through editing/activation), and better handling of deletion of content directly from the repository browser for non-empty packages.

RepositoryBrowser.png

The Project Explorer has similar new features added to the Team Menu. In SPS06, the feature to view the Catalog for the system shared to the project was added. In SPS07 this feature is expanded to include the Repository Browser within the Project as well.

ProjectExplorer.png

There is a whole new tool and perspective added for synchronization services.  This is especially useful when needing to view pending changes, such as deletions, for which there are no local resources.  For a full demonstration of this new synchronization tool, I recommend the following video:

https://www.youtube.com/watch?v=jog0ih6Qc54#t=438

There was also a focus on developer productivity throughout the tools in HANA Studio. For instance there are now File->New wizard entries for all the development artifacts in HANA development. These not only make getting started easier, but also eliminates the difficult to troubleshoot misspelling of file extensions.

New_Wizard1.png

Remember all those times in SPS05 or SPS06 where you would have type the full URL of a service or web page to test it in the browser.  Well now those days are gone thanks the Run As feature.  This allows you to test XSJS, XSODATA and HTML content directly from the Project Explorer.  The content will open automatically in your default web browser.

Other enhancements include a new Activation Dialog which displays all inactive objects across all projects for the same repository workspace.

MassActivation1.png

We also have a new generic text editor which is mapped to all artifacts without their own specific editor.  Today this this text editor may not seem like much, but it lays the foundation for future artifact specific enhancements such as syntax highlighting and code completion.

Web-based Development Workbench

Of course we also have many new and enhanced features in the Web-based Development Workbench tools as well. In fact there were so many that I broke that topic at into its own blog:

What´s New? SAP HANA SPS 07 Web-based Development Workbench

Change Manager

A major, optional enhancement to the general development workflow in SPS07 is the new Change Manager functionality. A common complain about the development workflow in HANA Native is the difficulty to handling transport of content out of the development system.  By transporting at the Delivery Unit level, it’s too easy to accidently take development objects which aren’t finished yet into a downstream system.

The Change Manager offers the automatic recording of all changes to a change list.  This change list must then be approved and released by all contributors to the change list.  This way it can’t be transported before all objects are ready to be moved. It, therefore helps support multiple streams of development within the same package in parallel, reducing the risk of accidentally transporting unwanted changes.

For a demonstration of this Change Manager and how it becomes part of the development workflow within the SAP HANA Studio, please see the following video:

Inactive Testing

Another new feature which helps with parallel development of the same objects is Inactive Testing. We’ve always had the ability for multiple developers to edit the same object at the same time.  Each developers’ changes are stored in their specific inactive workspace. However before anyone could test or debug the changes, activation was necessary. At the point of activation, a merge of any pending conflicts would need to take place. Of course once a change is active it could also accidentally be transported (see above for a similar discussion around the Change Manager).

To better support such parallel development, testing of the inactive version of XSJS, XSJSLIB, XSODATA or static web content is now possible in SPS7. This allows a developer to test their localized changes directly from the server without overwriting or having to merge with other pending changes.

The requirements for using inactive testing are as follows:

  • The server must be running in developer_mode
  • On the client side set a cookie named sapXsDevWorkspace to the name of your Repository Workspace

For a complete demonstration of how to use inactive testing, please refer to this video:

Core Data Services/HDBDD

Core data services (CDS) is a new infrastructure for defining and consuming semantically rich data models in SAP HANA. Using a a data definition language

(DDL), a query language (QL), and an expression language (EL), CDS is envisioned to encompass write operations, transaction semantics, constraints, and more.

A first step toward this ultimate vision for CDS is the introduction of the hdbdd development object in SPS6. This new development object utilizes the Data

Definition Language of CDS to define tables and structures. It can therefore be consider an alternative to hdbtable and hdbstructure.

In SPS07 we continue to expand upon the promise of CDS as a further abstraction layer. In addition to defining entities, it can now also express the relationship

between entities via Associations. For example, this syntax defines a header/item set of tables but also defines the relationship as well:


context Purchase {
@Catalog.tableType : #COLUMN
    Entity Header {
        key  PURCHASEORDERID: BusinessKey;
        HISTORY: HistoryT;
        NOTEID: BusinessKey null;
        PARTNER: Association to MasterData.BusinessPartner;
        CURRENCY: CurrencyT;
        GROSSAMOUNT: AmountT;
        NETAMOUNT: AmountT;
        TAXAMOUNT: AmountT;
        LIFECYCLESTATUS: StatusT;
        APPROVALSTATUS: StatusT;
        CONFIRMSTATUS: StatusT;
        ORDERINGSTATUS: StatusT;
        INVOICINGSTATUS: StatusT;
    };
@Catalog.tableType : #COLUMN
    Entity Item {
              key  HEADER: Association [1] to Purchase.Header {PURCHASEORDERID};
        key  PURCHASEORDERITEM: BusinessKey;
        PRODUCT: Association to MasterData.Products;
        NOTEID: BusinessKey null;
        CURRENCY: CurrencyT;
        GROSSAMOUNT: AmountT;
        NETAMOUNT: AmountT;
        TAXAMOUNT: AmountT;
                    QUANTITY: QuantityT;
                    QUANTITYUNIT: UnitT;
                    DELIVERYDATE: SDate;
    };
};

But these associations can also be used within the new View definition within HDBDD. Why redefine the relationship between objects over and over again within each view. Instead define it once centrally when creating the tables and allow all views to look up and reuse this relationship. This simplifies the syntax of the view creation considerably.  For example a view upon the header/item example above would look like the following:


   define view ItemView as SELECT from Purchase.Item {
      HEADER.PURCHASEORDERID as "PurchaseOrderItemId",
      PURCHASEORDERITEM as "ItemPos",
            PRODUCT.PRODUCTID as "ProductID",
            CURRENCY as "CurrencyCode",
      GROSSAMOUNT as "Amount",
      NETAMOUNT as "NetAmount",
      TAXAMOUNT as "TaxAmount",
            QUANTITY as "Quantity",
            QUANTITYUNIT as "QuantityUnit",
            DELIVERYDATE as "DeliveryDate1"
   };

Notice how no join criteria are specified. A field from the header table can be referenced simply by adding the entity name to the beginning of the field (HEADER.PURCHASEORDERID).

Of course once you start creating relationships between objects, a graphical tool to visual describe these relationships becomes so much more important. To that end, CDS/HDBDD now has a graphical tool to supplement the existing code based editor.

CDS_Graphical1.png

For a video demonstration of CDS/HDBDD:

Job Scheduling

One of the most often requested features is to be able to schedule jobs within HANA itself. Up until this point you’ve often needed to resort to scheduling jobs via the operating service on the HANA Server. But even that really only allowed for easy execution of SQL/SQLScript.

The new XS Job Scheduler allows for the periodic scheduling of both SQLScript Procedures and Server Side JavaScript. For a full preview of how to define and

schedule jobs for both development object types, please see this video:

XSCron1.png

XSODATA JavaScript Exits

Similar to the role of XSJS in SPS05, XSODATA services are already established as the quickest and easiest way to generate read-only REST services from existing tables and views within HANA. In SPS06, those capabilities are complemented with new support for Create, Update, and Delete operations as well.  No longer are you required to create a custom service in XSJS if you only need to add simple update capabilities to your service.

Furthermore, if you needed some simple validation or other update logic; in SPS06 it could be coded in a SQLScript exit mechanism from within the generic XSODATA service framework.

However SQLScript isn’t always well suited to the kinds of imperative logic you might want to place in these validation exits.  In SPS07 this functionality is

extended to also include Server Side JavaScript based XSODATA exits.  XSJS exits also allow for better manipulation of the data returned from the service exit and the option to also make outbound HTTP requests as part of the OData processing.

SQLScript

All the details about new features in SQLScript have been covered by my colleague Rich Heilman in this blog:

http://scn.sap.com/community/developer-center/hana/blog/2013/12/03/new-sqlscript-features-in-sap-hana-10-sps7

To report this post you need to login first.

28 Comments

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

  1. Alexander Glauberman

    Hi Thomas,

    Relating to new ‘Association’ feature:

    In your example with “Header” and “Item” entities, the one-to-many association created additional reference column in the Header table that points to a records in the Item table. Such physical structure a little bit confusing me because in case one Header has several Items we should see several records in the Header table. On the one side it is duplication of data and on the other side, how it is going with uniqueness of Header records?

    Thanks and Regards,

    Sasha

    (0) 
    1. John Appleby

      Hi Sasha.

      The association is just a join and it creates a SQL View to match the join type.

      I don’t believe it creates reference columns, foreign key constraints or anything else. On the Header table there is a primary key so that has a uniqueness constraint built in.

      John

      (0) 
    2. Thomas Jung Post author

      >Such physical structure a little bit confusing me because in case one Header has several Items we should see several records in the Header table.

      No. All it inserted into the header table was the key column PurchaseOrderId.  This is the join criteria.  This is a column you would obviously need with or without the association.

      (0) 
      1. Alexander Glauberman

        Hi Thomas,

        OK, may be it is not a good example for my question. Let’s take other two entities: Person and Phone, where Person has one-to-many association to Phone.

        entity Phone {

           key id : Integer;

           number : String(20);

        };

        entity Person {

           key id : Integer;

           name : String(50);

           phone : Association[1, 0..*] to Phone;

        };

        The generated table Person will have three columns: ID, NAME and PHONE.ID and table Phone will have two columns: ID and NUMBER.

        My question: How the content of these two tables should look like if person with ID=1 has two telephone numbers? Does the Person table will contain two records?

        According to my understanding of this case, the one-to-many relationship my be implemented by adding column PERSON.ID to the Phone table instead of having PHONE.ID column in the Person table, but it is not align with new Association feature.

        Regards.

        Sasha

        (0) 
        1. Thomas Jung Post author

          Your example wouldn’t work for a situation where you want multiple phone numbers per person.  For that situation I would recommend something like this:

          entity Phone {

             key id : Association[1,0..*] to Person;

             key type: String(4);  //Work|Mobile|Personal

             number : String(20);

          };

          entity Person {

             key id : Integer;

             name : String(50);

          };

          Of course you could then create view that uses this relationship, but every time you have multiple numbers the join will return multiple records.  This is why in this particular example you often instead find multiple phone numbers normalized down into separate columns in a single record.

          More to the point of your main question is that you can absolutely set the association at the child level.  For example I’ve since adjusted my purchase order example to place the association at the item level and I like it much better:

          @Catalog.tableType : #COLUMN

              Entity Header {

                  key  PURCHASEORDERID: BusinessKey;

                  HISTORY: HistoryT;

                  NOTEID: BusinessKey null;

                  PARTNER: Association to MasterData.BusinessPartner;

                  CURRENCY: CurrencyT;

                  GROSSAMOUNT: AmountT;

                  NETAMOUNT: AmountT;

                  TAXAMOUNT: AmountT;

                  LIFECYCLESTATUS: StatusT;

                  APPROVALSTATUS: StatusT;

                  CONFIRMSTATUS: StatusT;

                  ORDERINGSTATUS: StatusT;

                  INVOICINGSTATUS: StatusT;

              };

          @Catalog.tableType : #COLUMN

              Entity Item {

                  key  HEADER: Association [1] to Purchase.Header {PURCHASEORDERID};

                  key  PURCHASEORDERITEM: BusinessKey;

                  PRODUCT: Association to MasterData.Products;

                  NOTEID: BusinessKey null;

                  CURRENCY: CurrencyT;

                  GROSSAMOUNT: AmountT;

                  NETAMOUNT: AmountT;

                  TAXAMOUNT: AmountT;

            QUANTITY: QuantityT;

            QUANTITYUNIT: UnitT;

            DELIVERYDATE: SDate;

              };

          I can then create views such as the following:

          define view POWorklistView as SELECT from Purchase.Item {

                HEADER.PURCHASEORDERID as “PurchaseOrderId”,

                PURCHASEORDERITEM as “PurchaseOrderItem”,

                HEADER.PARTNER.PARTNERID as “PartnerId”,

                HEADER.PARTNER.COMPANYNAME as “CompanyName”,

                HEADER.GROSSAMOUNT as “GrossAmount”,

                CURRENCY as “Currency”,

                HEADER.LIFECYCLESTATUS,

                HEADER.APPROVALSTATUS,

                HEADER.CONFIRMSTATUS,

                HEADER.ORDERINGSTATUS,

                PRODUCT.PRODUCTID as “ProductID”,

                PRODUCT.NAMEID,

                PRODUCT.DESCID,

                PRODUCT.PRICE as “ProductPrice”,

                PRODUCT.PRODUCTPICURL as “ProductURL”,

                HEADER.PARTNER.ADDRESSES.CITY as “PartnerCity”,

                HEADER.PARTNER.ADDRESSES.POSTALCODE as “PartnerPostalCode”,

                GROSSAMOUNT as “GrossAmount_1”,

                NETAMOUNT as “NetAmount”,

                TAXAMOUNT as “TaxAmount”,

             QUANTITY as “Quantity”,

             QUANTITYUNIT as “QuantityUnit”,

             DELIVERYDATE as “DeliveryDate”

             };

          (0) 
          1. Alexander Glauberman

            Hi Thomas,

            Thanks for clarification, now it is much more clear.

            At the same time the documentation of “SAP HANA Developer Guide SP07” includes a lot of examples of one-to-many association between Person and Address entities where association is defined on the parent level (on the Person). The syntax enables that, but according your explanation and according to straightforward logic such association should be defined on the child level, e.g. on Address entity. If that correct, should the guide examples be changed, and more over, may be the syntax of association should be restrict in order to prevent non-correct usage.

            Regards,

            Sasha.

            (0) 
  2. Alexander Glauberman

    Hi Thomas,

    One more question:

    In your example of CDS definition the column names are low case and, in the generated table, the columns also are low case.

    In my test environment (also HANA SPS 07) I get different picture: in CDS definition columns are defined with low case, but in the table I get upper case column.

    For example:

    @Catalog.tableType: #ROW

      entity Country {

      key code : String(10);

      name     : String(50) not null;

      };

    /wp-content/uploads/2013/12/table_def_350020.png

    Best regards

    Sasha

    (0) 
    1. John Appleby

      I’m guessing it is because you are using the row store. Please don’t use the row store unless you know exactly why you are doing so.

      Try recreating it as a column store object.

      (0) 
    2. Thomas Jung Post author

      The case sensitivity within HDBDD is something that underwent some last minute changes.  As I prepared my videos on an early internal build they might not match exactly the case sensitivity rules that finally shipped with HDBDD.  If you want lower/mixed case columns you can always put them the attribute names in quotes.

      (0) 
  3. Fnu Shakir Ahmed

    Hi

    I just installed the latest studio (version 70) and tried to check out an empty package.

    The folder/directory structure was not created in the workspace directory.

    Is it a bug or intentional behaviour?

    Best regards,

    Shakir

    (0) 
      1. Fnu Shakir Ahmed

        Does it mean that one has to create a Project in HANA Studio with “Use default location” and later link it with the repository workspace when sharing the Project?

        (0) 

Leave a Reply