I managed to get my hands on Nakisa 3.0 and get it deployed in our new NetWeaver CE environment. Luckily that was a fairly straightforward process! The instructions provided by Nakisa are fairly comprehensive.
I wanted to follow up on my What's new in Nakisa 3.0 blog, which covered the new functional functionality, by covering the new technical functionality. This is really aimed at you Technical Consultants or Solution Architects who are going to be designing or configuring Nakisa solutions.
The new features I've found so far in 3.0 are:
- AppResources structure
- downloadSchema structure
- Publish changes straight into run-time (no NetWeaver CE restart)
- Multi-Tenancy
- Configuration Import/Export
- Add-Ons features
- Data Center
- AdminConsole Login
- Flash-based charts and OrgChart Mode
- New printing module
- Re-designed Chartbook function (SP1)
- Internet Explorer compatibility
- Reading logs through Admin Console/Data Center
- Java application structure (for previously .NET users)
The last section is not really new, but for those that have only used the .NET versions it can be useful for finding your way around the Java version a bit quicker.
For most of the AdminConsole based features it is definitely worth reading the relevant section in the Admin guide PDF to get a greater understanding of how it works from a user, administrator and SI perspective.
Java
Nakisa have done away with the .NET version and switched over to SAP NetWeaver technology fully. This is a bold move given some of the noises going around about the future of Java. It also helps it align fully with SAP technical strategy going forward. This can only be beneficial given that .NET is a more programmer orientated environment and some of the errors only make sense to those that have done programming in the past in C# or VB etc.
AppResources structure
One of the most significant changes to the new release is the way the old AppResources.xml is now structure. I say old, because this file no longer exists in 3.0. In order to allow upgrades and import/export of configurations Nakisa have split AppResources.xml up into a number of folders representing each configuration section, with each of these folders containing an XML file for each individual configuration. It might help to understand with an example. In OrgChart (Live), the folder AppResources, found in \root\.system\Admin_Config\<build>\, is split into the following sub-folders:
- dataconnectionconfiguration
- dataelementconfiguration
- detailconfiguration
- detaildataconfiguration
- detailspresentationconfiguration
- directoryconfiguration
- expertseekprofiledatasourceconfiguration
- floorplanconfiguration
- formconfiguration
- hierarchyconfiguration
- inputformconfiguration
- kpiconfiguration
- linkconfiguration
- listingconfiguration
- moduleconfiguration
- orgchartconfiguration
- quicklistconfiguration
- reportconfiguration
- searchconfiguration
- selectionvalueconfiguration
- selectionvalueconfiguration
- selectorconfiguration
- styleconfiguration
- taskconfiguration
- themeconfiguration
- tocconfiguration
- validationconfiguration
- viewconfiguration
For those of you familiar with the AppResources.xml from previous versions, this structure will be fairly familiar. Now take the orgchartconfiguration folder, this has 5 XML files in it. Again, for those familiar with AppResources.xml these names will be familiar:
- OrgUnitOrgChartCount.xml
- PositionReportingChart
- SAPOrgUnitEmployeeOrgChart.xml
- SAPOrgUnitOrgChart.xml
- SAPPositionReportingChart.xml
And each of these files contains the configuration of that name. Simples.
downloadSchema structure
Similarly to AppResources, downloadSchema is now split in a similar, although different, way. This is split into 3 XML files covering the main 3 configuration sections, rather than being 3 folders containing the individual configurations. In the SAPExtractor subfolder, found in your build folder, is a subfolder called extractorSchema. This contains:
- extrainfo.xml
- functionConfiguration.xml
- joinConfiguration.xml
Each configuration section file contains all of the configurations for that section.
Publish changes straight into run-time
In the previous Java version the NetWeaver CE instance needed a restart after any configuration changes. In this version when you hit Publish in the Admin_Config the changes take effect straight away without requiring a refresh of the instance.
Multi-Tenancy
This is a great new feature for 3.0 that allows the use of multiple builds (known each as a "Tenant") on a single application instance. This means different configuration builds can be created and assigned to different user groups. This does not remove the use of security, rather it makes different builds available to certain wider user groups that may not be based on roles but based on companies, locations or systems. This feature, once enabled through ManagerResources.xml, is found in the Application-Wide Settings module of the AdminConsole.
For example, you may secure certain features in your main configuration (the "Master" tenant) but you may have a different configuration for certain user groups that disable features from all users. One of my clients wanted a different build on their Intranet (a more of a "Who's Who" directory version) that had the details panels disabled and no export functionality, while on their NetWeaver Portal they wanted a build with all functionality plus some significant customisations. This was only possible with 2 separate application instances, which creates difficulties with maintenance.
Another main reason for using different Tenants is that you may have different companies that have different SAP systems. You would therefore want each one to access different builds as their data connection (and possibly SAP-specific data configurations) will differ from other companies. And of course there is the huge benefit of being able to use different instances from one backend SAP system in one application instance. I have been told that this also adds some On Demand/SaaS functionality that wasn't previously available in the Nakisa solutions.
Configuration Import/Export
One of the new features is the ability to import and export configurations. This allows you to export a configuration to a parallel instance, say in your DEV environment, or to your QAS or PRD environments. This allows customers or SIs to create configurations on their sandpit systems before importing into the target client system for testing. This is similar to the excellent Add-Ons features specified below.
Add-Ons features
The 3.0 AdminConsole introduces the Add-Ons Manager and Export Add-Ons (in Application-Wide Settings). This allows the export and transfer of changes in builds or specific configurations for transfer to another system (either in the same landscape or a different landscape). The Add-Ons manager also allows the testing of add-on enhancements and customisations and, of course, the disability to disable any enhancements or customisations. The Add-Ons manager can also use precedence between new and existing Add-Ons in order to use the right version.
Add-Ons in 3.0 are usually one of the following:
- Changes made to the build in the AdminConsole
- Customizations made by SIs or Nakisa
- Enhancements or hotfixes
- Service Packs
The Export Add-Ons feature allows the user to export a particular AppResources configuration or export an entire build of changes. This allows advanced users to be able to upgrade from this version to future versions of the applications, rather than re-configure a new build in the target application. This is a massive plus from this version.
Data Center
The Data Center is another great new feature in the AdminConsole (in Application-Wide Settings) which allows the management of data connectivity and configuration in the applications. The Data Center allows the user to read SAP data tables, test SAP BAPIs (custom or otherwise), read database tables, configure the Live extractor keywords (known as ABAP Add-on Parameters in the AdminConsole) and manage all the connection configurations, including testing connection strings to SAP.
It is pretty straightforward to use and doesn't really involved a great deal of technical knowledge of data connections.
AdminConsole Login
A new feature of the AdminConsole is the ability to configure user logins. Anybody who tried the previous version of securing the manager.aspx file would have found it was incredibly difficult to prevent access to the manager URL. No access to the URL is not prevented, but the actually AdminConsole is password protected. There is a default username and password that can be changed and multiple new users can be created simply in the Security section of the AdminConsole. It is also possible to change the password and delete users. For me this gives much more robust protection of the AdminConsole and to prevent unauthorised and potentially damaging access.
Flash-based charts and OrgChart Mode
Another new feature is the use of Adobe Flex-based Flash charts. This gives a much better user-experience in terms of quality, navigation and ease-of-use.
I also like that the user and client have the ability to switch between the new Flash-based charts (known as “Standard Mode”) and the old HTML-based orgchart (known as “Basic Mode”), through the user Preferences or through the AdminConsole module called OrgChart Modes. It is also possible to disable either of the modes, should it be required.
New printing module
As part of the Flex redesign Nakisa have finally fixed the weakest link in their applications, printing. Printing using European paper sizes has proved immensely difficult and problematic for all of my previous and current clients (and I have quite a lot). I’ve generally found that previously you had to set some settings, like paper orientation, 2 or 3 times in the application, browser and sometimes printer settings. A3 printing hasn’t even worked properly for some clients no matter how much they followed Nakisa Best Practices for Printing instructions. Luckily, these issues should be a thing of the past.
I’ve tested the printing on a few different printers and found a significant improvement in getting out of the printer what I see on my screen. I found some issues with one printer, but Nakisa have since told me that they have fixed a few issues with the printing module. This will hopefully be part of SP1 for 3.0.
Re-designed Chartbook function (SP1)
As part of 3.0, although only delivered with Service Pack 1.0, will be a newly designed Chartbook function. This is to coincide with the design of the print functionality into Adobe Flex. At present I don’t have any details but given the number of enhancements due in Service Pack1.0 I will probably post another blog nearer its release date.
Internet Explorer compatibility
From 3.0 there is Internet Explorer compatibility with version 8 but the suite no longer supports version 6. This is generally to do with some of the Web 2.0 features that Nakisa have introduced into the applications.
Reading logs through Admin Console/Data Center
In Service Pack 1.0 the ability to read logs through the Admin Console or Data Center will be available. This allows the user a “one-stop shop” to identifying errors and being able to solve them while in the Admin Console. Of course for advanced users this will not provide much additional benefit, but for those doing basic configurations it can definitely provide some benefits.
Java application structure
While the Java version is not new in 3.0, it is the exclusive application architecture now that the .NET version has been discontinued. So, for those who had only previously used the .NET version I am going to try and highlight some of the differences between the Java and .NET application structures.
First the Java version has a few more layers of folders to go through to get the actual application folder. A typical folder path to the Nakisa applications would be:
\usr\sap\<sid>\<java instance id>\j2ee\cluster\apps\Nakisa.
<sid> is your SAP system ID and <java instance number> is, not surprisingly, your java instance (e.g. J00 or J10). A typical folder path to the OrgChart application would be:
\usr\sap\<sid>\<java instance id>\j2ee\cluster\apps\Nakisa\OrgChart\servlet_jsp\OrgChart\root
Inside the root folder you will find most of the folders you would expect to see in the OrgChart folder in the .NET version (such as Documentation, Images, Language, Log, Templates, XML etc). However, one folder missing is the Admin_Config folder. Do not be scared! Nakisa have moved config into the .system folder that is found in the root folder. In the .system folder you will find Admin_Config and also the add-ons folder.
One of the other important changes to the structure are the way the builds are named in the Admin_Config folder. Because of Multi-Tenancy the application creates a “Master” tenant build (this is your normal build), even if you never use Multi-Tenancy. The format is usually:
__000___<build name>
For other Tenants the 000 will become 001, 002 etc. Another good feature is the ability to create custom folders inside the build that will then publish into the root folder. For example, in \<build>\root\ you can create a folder called Templates_Client. When you publish your build a folder called Templates_Client will be created in the root folder. Any subsequent publishing of your build will write the files in the \<build>\root\Templates_Client folder into the \root\Templates_Client folder.
It is also worth noting that when you include a new jar file into WEB_INF\lib then you have to re-deploy the application with the new jar deployment file. However, once this has been deployed you can simply overwrite the jar file with an updated version as and when required. Only a restart of the instance is required because the initial deployment registers the new jar files name.
Special thanks go to Stephen Burr for pointing out the last 2 Java tips and to Dave Jones, VP of Product Development at Nakisa, for double-checking I hadn’t missed out anything important.
- SAP Managed Tags:
1 Comment
