Nakisa Tenants Configuration

[MarkLittle]

Hi,

I am configuring Nakisa for the first time for a simple build for the purposes of publishing a couple of Org Structures. All is going OK as it can and I have only a couple of issues I am trying to sort out.

  I am struggling with understanding the “Tenants Configuration” so I need some guidance from anyone who have used this feature.

Build Scenario

I am required to have several published Org Structures due to multiple companies existing in the overall org structure.

• Company A, will have view access to all the underlying structures (ie ALL)
• Company B is a sub structure of A that I require a separate publish/ build for. (ie separate URL that will be put on separate companies
  intranet site)

Issues

Enter Nakisa and select a build name and publish this build this exists as the default published structure as per following URL.

http://sapXXX:XXXXX/OrgChart/default.jsp

How does the tenant config work in relation to assigning a URL to a build? I tried a few things but none of them seem to work. Do I not need multiple
builds for multiple tenant publishes (ie Can I have one build and several tenant entries….how does this link back to a parent org unit)

I checked all of the Nakisa documentation and there is nil in relation to how this works, one would think that since this is new
functionality that some documentation would exist around how this works. Unless I missing something ?

Any help much appreciated.

Thanks

[Former Member · Accepted solution]

Hi Mark,

We had the same question this past summer, and approached Nakisa directly. From my understanding, the multi-tenant functionality is developed and enabled in the product, but it is not certified for release to customers. Hence, the lack of official documentation (a little frustrating, I know).

That's not to say it doesn't work if you configure it, but Admin Guide documentation with the configuration steps required most likely will not be coming until it is certified for customer use.

Cheers!

Matthew

[MarkLittle · Accepted solution]

Hi Matthew,

Thanks for the info. Agree will you about this undocumented functionality, akin its like selling me a car with lots of buttons that will be switched on 6 months after you purchase it. I truely wonder sometimes !

Anyway I am going to have a go at building it, I have some ideas on how it may work from spending a bit of time on it already. So if I work it out I will post the solution.

[Former Member · Accepted solution]

Hi Mark,

That's the spirit! I'm sure you'll be able to figure it out. Here are a couple of basics that I figured out:

- Once you enable a tenant and assign it a tenant ID (###), in AdminConsole you receive the option to login as 'admin' for that tenant and change the tenant configuration

• To change your master tenant configuration you must login as 'admin'/<password> using tenant ID 000.

- It seems you can only really work on the "master build" and save changes directly to it.

• i.e. If you are using SAP_Live_RFC as your master configuration, then change it in AdminConsole and do not use the "Save As" button to rename it.

- The reason for the above is that when you want to modify a tenant configuration based on your master configuration, you only have the option to load SAP_Live_RFC or SAP_Staged

• So, if you login with 'admin'/<password> using your newly created tenant ID, and make modifications to SAP_Live_RFC, for example, you are in fact creating a delta configuration from the  master copy of SAP_Live_RFC which you previously configured with admin(000).

- The end result is, you can create multiple tenants which all share the same configuration initially, but then you can reconfigure any of their tenant specific settings (data connection, security settings, chart root, etc.)  which require different configurations from your master tenant configuration.

And here's a little tip that was shared with me by Nakisa (though I don't remember now if I tested it myself or not):

- If you don't want tenant users to input their tenant IDs on the login screen (which they may not remember on top of their username and password), you can pass the ID through the URL used to load the user interface as follows:

• .../OrgChart/default.jsp?TenantKey=100
• .../OrgChart/default.jsp?TenantKey=200
• etc.

The above would be very useful in my view, since I am always forgetting my passwords and having to remember other credentials on top could cause annoyance for some users.

Happy exploring,

Matthew

[MarkLittle · Accepted solution]

Thanks I will let you now how I go

[Former Member · Accepted solution]

No problem, Mark. Good luck!

[MarkLittle · Accepted solution]

Hi Matthew,

I have done some testing on this with little success.

I set up the multi-tenancy setting/s as recommended and subsequently logged into each of these clients (001 and 002) and setup the required config. Saved and published the separate instances.

Note : (tried both standard and domain for “Provider” settings as above)

When going to the URL xxxxx/OrgChart/default.jsp?TenantKey=002 I do get results appearing but these are from the publish of the default or master build in 000. It seems when I publish either of the tenant (001 or 002) builds it doesnt transfer results to this extension, or maybe there is another component to this that I am not aware of?

I changed the URL extension over and over, after the /default.jsp, and anything post this extension really does nothing. For example if I use the following (which is not valid)  /OrgChart/default.jsp?marklittle  it still brings in the results of the client 000 Master build (ie /OrgChart/default.jsp) so the extension of TenantKey=002 or marklittle doesn’t seem to reference anything.
Unless I am missing a character extension ?

I have seen another post regarding this URL extension and he did not have much luck with identifying what it should be, or even if works ?

Do you remember anything special when you were messing about with these URL's for the tenant id's ?

Thanks

Mark

[Former Member · Accepted solution]

Hi Mark,

The TenantKey URL was shared with me directly by Nakisa product development, but I do not recall if I tested it myself. I will have to find my build with the working multi-tenant configuration, and retest. I'll let you know the results when I get a chance to do so.

Also, they noted that you should not need to publish anything but the master tenant configuration (000). This sounds a little illogical to me since I don't see how the application knows that any individual tenant configuration is complete (eg. 001, 002, and so on), but I suppose if you merely "Save" the changes to a tenant configuration the application will still read the delta config you've made for that tenant and apply it upon a user logging in with the same tenant ID.

At some point, I do know that I got two tenants working for two different SAP backend clients (100 and 200), but I was also only using the logon screen in which I must explicitly provide the tenant ID along with my R/3 credentials. In the end, I was able to visualize three different structures in the same application. The master tenant config was rooted at the whole organization from client 100, the tenant 100 was rooted at some substructure from client 100, and tenant 200 was displaying some structure from client 200.

I believe I have since undeployed the instance in which I configured all this (not purposefully, but merely because my Tomcat was using far too many system resources and I needed to lighten the load). So, I'll have to setup a new config and retest, because now you've got my curiosity peaked again.

Cheers

Matthew

[Former Member · Accepted solution]

Oh, by the way, regarding your screenshot, I believe you should be able to leave the domain as the default value, or merely make it your network domain name (eg. mycompany.net). The full URL link to the tenant instance should not be there.

[Former Member]

Dear Mark,

Thank you very much for your work, I know it's not finish yet, but thanks for giving me a clue on how to perform the multi tenant configuration.

I guess I am going to continue your work on my thread

Regards,

Bobbi

[MarkLittle]

Sorry All,

I ran out of time to try and solve this due to other project commitments, so we went with what we had as I could not get the Tenants Configuration to work in the end.

Thanks all for your responses they gave me some more insight into what this functionality is supposed to do.

Regards,

Mark

[Former Member]

Hi Mark

Is there any reason why you are not using Roles or Structural Authority to separate access to the same Org Structure or even segregate access into two hierarchies in the same Build or Instance. For Instance use authorities from the back end, or your own if staged build, as one option or create a second hierarchy with a different route Org Unit as a second option with both hierarchies separate by roles in security linked to employees in each company code.

There is also the option to use dynamic authorisations to drive access to parts of the structure but this is more difficult.

As for Tenancy we did get it to work of sorts but used in a training scenario rather than for a production scenario. We didn't test to the nth degree but did have some success and would second the comment above that you should think about the impact on resources the more tenants you create. I think the key is the order in which you activate tenancy, i.e.

1.) Enable Multi-Tenancy in Application Wide Settings (Save and Publish important bit)

2.) Create Tenants (Provider can be left as standard and Domain didn't need to set anything here)

3.) Create an Admin account for each Tenant and assign to the respective Tenant (Save and Publish)

There is a Tenants folder in the Published XML directory so this suggests you can configure and publish each Tenant separate to the original Master Build.

We tried this in a Tutor/Student scenario and the main issue was performance, though mainly due to poor sizing and also sometimes the configurations didn't appear to update but other times they did.

This is from Nakisa instructions and without extensive testing but we did have some success, hope it works for you.

I think this will be a good blog subject so I might have a go of publishing our findings over the next week or two.

Regards

Stuart