Like last time, I'll give the community a brief overview of the new and improved topics in the SDK for Design Studio 1.5.
While in 1.4 there were many new features to announce, this time we focused on smaller improvements - following the suggestions from the community.
You might know that the axes of a cross table does not only contain dimensions and their members, but also display attributes - or shortly attribute. A dimension "ShopCity" might have the attributes "Latitude" and "Longitude" - and accordingly the member "London" has the attribute members "51.5" and "-1.5".
Attributes are part of the result set if they are activated, e.g. in Query Designer. In this case the Crosstable shows additional columns or rows - right beside/below the member presentation (key, text) column(s) or row(s).
In 1.5 SDK components can request attributes and attribute members with the property option
<option name="includeAttributes" value="true"/>.
At runtime in the SDK result set JSON, you receive the activated attributes as part of the dimension metadata, and the attribute members as part of the member metadata. The following data snipped uses attributes for country and postcode on the customer number dimension.
{
"key":"0BC_CUST",
"text":"Kundennummer",
"axis":"ROWS",
"axis_index":0,
"attributes":[
{
"key":"0BC_COUN",
"text":"Land"
},
{
"key":"0BC_POST",
"text":"Postleitzahl"
}
],
"members":[
{
"key":"000001",
"text":"Techno\x20Graph\x20Ltd.",
"level":3,
"attributeMembers":[
{
"key":"US",
"text":"US\x7cVereinigte\x20Staaten"
},
{
"key":"0000054323",
"text":"54323"
}
]
},
...
The Simple Crosstab sample has been extended to display attributes and there members in extra columns - just like the "real" Crosstab.
The second frequently requested feature is Conditional Formatting - also known as "Exceptions". The Query contains conditions under which some values of a result set should be formatted, e.g. critical numbers should be shown in red.
Again, you can request the feature with an option:
<option name="includeConditionalFormats" value="true"/>
Now you need a result set with some Exception definition. You could e.g. specify some exceptions in A-Office and smart-paste the query to Design Studio.
In this case your would get the available exception types as new metadata property:
"conditionalFormats":[
{
"key":"LocalException\x2d1",
"text":"Conditional\x20Formatting\x201",
"com.sap.ip.bi.bics.exception":{
"FORMATTYPE":"4"
}
},
{
"key":"LocalException\x2d2",
"text":"Conditional\x20Formatting\x202",
"com.sap.ip.bi.bics.exception":{
"FORMATTYPE":"16"
}
},
{
"key":"LocalException\x2d3",
"text":"Conditional\x20Formatting\x203",
"com.sap.ip.bi.bics.exception":{
"FORMATTYPE":"8"
}
},
{
"key":"LocalException\x2d4",
"text":"Conditional\x20Formatting\x204",
"com.sap.ip.bi.bics.exception":{
"FORMATTYPE":"2"
}
}
]
...
And as part of the data, you receive a new array with the same length as the data array:
"conditionalFormatValues":[
null,
null,
null,
null,
null,
null,
{
"LocalException-1":1
},
null,
null,
{
"LocalException-1":1,
"LocalException-3":2
},
...,
As you see, not all cells have exceptions - and some have multiple. What you do with the numbers is up to you. The Simple Crosstab again has been extended to behave similar to the standard Crosstab and add some exception-specify CSS classes - which can be used to change background color or attach some icon to the cell.
Another frequently requested "feature" was the increase of the cell limit to higher values than 10.000 cell. Now - the cell limit is in fact not a missing functionality, but a safety belt to you as component author and you customers - to avoid JSON transfer volume that can hurt stability and performance of customer's apps, browsers and servers.
But in cases where an SDK component has been tested successfully with a certain number of cells, the author can specify a cell limit that is good for his or her component. The setting is per data-bound property:
<option name="maxCells" value="15000"/>
If wrongly used such option could influence a whole BIP system. Therefore we have a new admin parameter AAD_SDK_MAX_CELLS which has a default value 50.000. Administrators can change it to higher or lower value, e.g. by changing the RSADMIN table for NetWeaver or adding a JVM argument "-DAAD_SDK_MAX_CELLS=<somesthing>. The lower of the SDK-component specific option and the admin parameter is used at runtime to decide if the error message "Too much data" should be displayed.
For SAP Components build in the "SAPUI5" handler type, two missing feature were added to correspond to the same functionality in "DIV"-components:
The Data Selection feature for SDK components and charts was always quite powerful. Unfortunately the UI in the Designer to configure such selections was not able to unleash all the features. Now we have a new Data Selection tool. Depending on the property type (selectionShape option), it supports all kinds of carthesian selections, including checkerboard stile. And it even works with custom data sources!
One of bigger features in release 1.5 is the possibility to bind potentially any property of any component to data from a result set - without scripting. This feature is inspired by the Excel cell binding in Xcelsius. I will probably write and extra blog describing the feature and the concepts behind.
SDK components can also leverage the feature. But as only the author of a component knows if binding a property makes sense and will work, it has to be enabled. This is easy - just set the new "bindable" attribute to true:
<property
id="color"
title="Color"
type="Color"
group="Display"
bindable="true"/>
A nice side effect of the property binding features now allows and SDK component to consume data from multiple data sources.
Just define multiple databound properties (type e.g. ResultCellSet) and make it bindable. Afterwards users can use the property binding UI to assign selections from the same or different data source. Selections could of course select an entire result set. This concept makes effectively the "databound" attribute and the implicit property "DATA_SOURCE_ALIAS_REF" obsolete, as a property binding for a databound property forms the combination of a data source and a data selection.
Base on these techniques I have created a new sample: The ScalingDataSource takes the result set from another data source (e.g. from BW or HANA) and scales some of the data values bases on a second data selection. It also shows some changes in the SDK DataBuffer to customize some of its data selection features.
The advanced features for Even Binding and "onBeforeRender" had some problem which are now solved:
Unfortunately we had to do some changes that could break existing SDK extensions. But is should be simple to fix them.
Finally there is a little experimental feature in the "Install Extension to Design Studio..." dialog. If you are choosing a file with extension "JAR", it will try to install it directly. This means that you don't need a "Deployable Feature" or "Eclipse Update Site" to install a single extension. Theoretically you could just use a ZIP tool to compress the source structure - and change the extension to "JAR". But please be warned: this is not any officially supported feature - and can fail. We could also change or remove the feature in future versions. Commercial extensions must ship in form of an "Eclipse Update Site".
Ok, that's all for 1.5 - if I didn't forget to mention something. As usual - I'm looking forward to you comments and suggestions.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
28 | |
13 | |
12 | |
11 | |
9 | |
9 | |
7 | |
6 | |
5 | |
5 |