cancel
Showing results for 
Search instead for 
Did you mean: 

OrgModeler Stage database

Former Member
0 Kudos

Dear Experts,

We are in the process of implementing Nakisa in our landscape, now we are configuring Nakisa Modeler.

Stage database configuration means, should i install separate Standalone database (Oracle, DB2 etc) for OrgModeler or should i use the same SAP Backend system database for the same.

Thanks

Sharif

Accepted Solutions (1)

Accepted Solutions (1)

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

OrgModeler needs its own database to store the scenarios in for modelling.  This will require its own database and will store data in a schema based on that defined by the user account and connection settings.

You should fully review the deployment guide (and environment check list) to verify the pre-requisites.

The "safest" approach in any scenario would be to utilise a new dedicated database instance.  In some scenarios it is actually imperative to do so.

Here's some things to consider...

  • If you are using Oracle, then note that you need an NLS_LENGTH _SEMANTICS property of CHAR but NetWeaver's recommendation is for BYTE, so you would absolutely require a separate instances for databases for these two systems ... but they can co-host on the same server.
  • If you are use SQL server, ensure that you specify a case insensitive collation for your instance.
  • The deployment guide lists several troubleshooting things for DB2, so they would be worth a read prior to deployment if you opt to go with IBM's offering.

Hope that helps.

Regards,

Stephen.

Former Member
0 Kudos

Dear Stephen,

Thanks for your reply.  Yes i read the Deployment guide as well.

I understand that we need dedicated Database server for OrgModeler configuration, can i install the Stage database in SAP Backend (Addon) host or Netweaver (Nakisa) Host ? is there any mandatory.

We are planning to have Oracle Database.

Thanks

Sharif

Former Member
0 Kudos

HI Stephen,

I have already configured Orgchart with SAPLive Build, in this case if i configure OrgModeler in Stage Database. it that works ?

Thanks

StephenMillard
Active Contributor
0 Kudos

Sharif.

There's nothing overly special about the database installations as far as I know.  The VSN applications don't really care where it is in so much as they just need to be able to connect to it across your infrastructure.

In general we find clients typically put the database on the NetWeaver server hosting the Nakisa application(s) or into a pool of existing database servers (occasionally as a new (typically virtualised) server).

Regards,

Stephen.

StephenMillard
Active Contributor
0 Kudos

Sorry Sharif, could you clarify what you mean by this statement?

A live OrgChart build will have a database only if you've included notes, database stored user preferences or SocialLink™ (or you actually deployed as a hybrid with staged analytics).  So it has no obvious bearing on an OrgModeler deployment's database requirements.

Regards,

Stephen.

Former Member
0 Kudos

Hi Stephen,

I am little confused here.  In OrgChart i am using SAPLive Build and in OrgModeler i am using SAPImage_Oracle Build.  Now still should i need to install separate database for OrgModeler ?

and while configuring ALE & Staging below are the screen, here i have entered SAP systems details and oracle db user name /. passwd.  is this correct or should i use stage database credentials.

Thanks

Sharif

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

OrgModeler always needs a database as per the requirements in the docs.  As per my original response I would recommend using a new separate database for any VSN application - including OrgModeler.  If you do happen to have a database for OrgChart (for possible reasons I outlined above), then I would still refer you back to creating a separate database purely for OrgModeler use.  It makes backup options more granular, simplifies the architecture for tracking down issues, etc.

The AdminConsole page in your screen shot is the settings for the destination of data OrgModeler is pulling in from ALE/IDOCS feed(s).  The destination will be the database you are asking about.  You should enter the details of your database here.

You can't enter the SAP system details on this particular page as it is details for a database and not a SAP connection.  You would never connect to the SAP system's underlying database directly and in fact to get to this page you should have entered your source SAP system details.

But I don't think it will allow you to configure it until you actually have your new database set-up and ready.

Regards,

Stephen.

Former Member
0 Kudos

Hi Stephen,

yes i have already entered "source - SAP" connection details and then enter details of SAPbackend DB user details in "Destination" ,  i think i am wrong here ?

Thanks

Sharif.

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

If you are entering the connection details for the ECC system's database, then yes you are wrong here; as per my previous response.


You would never connect to the SAP system's underlying database directly

Regards,

Stephen.

Former Member
0 Kudos

Hi Stephen,

Yes correct, now i have removed those entries in orgmodeler in admin console.

can you please correct me if im wrong in the below sequence.

1. I have installed nakisa add-on / TR's and .sca files deployed in nw portal.

2. configured OrgChart using SAPLive Build using orgchart admin console and followed nakisa standard document.

3. Now we are planning to configure orgModeler. and for this we need to install Stage data base for further configuration correct?

thanks

Sharif

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

As per the deployment guide, you should first implement the Nakisa ABAP add-on and the Nakisa Transport Package prior to implementing any VSN module (/application).

Next you would deploy a VSN module by installing the SCA file into the NetWeaver server.

Most organisations choose to deploy OrgChart as their first module, but there is no order in which to deploy VSN modules.  Each VSN module can be deployed independently of another - but they do share the same back-end components (as well as requiring additional ones such as ALE/IDOCS, TREX, etc.).

Every VSN module has a set of pre-requisites.  One of the pre-requisites for OrgModeler (as has been discussed here at length) is that of a database in which to store the modelling data.

In order to configure some connections in a VSN module's AdminConsole it may attempt to verify the connection and at the very least offer you a method by which to test and verify it.  If your database is not in place then you would not be able to specify and validate/test the connection to it.

The most logical implementation approach would be to ensure all of your system pre-requisites are in place prior to beginning any configuration work.  This would include not only the database, but also for example a version of the SAP Java Connector compatible with your selected module and version.

Regards,

Stephen.

Former Member
0 Kudos

Hi Stephen,

Thanks a lot for the detailed explanation.

Now i will install a Oracle DB in NW host and proceed with further orgmodeler configuration.

Thanks

Sharif.

Former Member
0 Kudos

Dear Stephen,

I have referred to Environment checklist in that, it is mentioned like use Separate DB for Audit/Chart/Modeler only if required, that means still we can use SAP Backend system DB.

I have also opened message with SAP before i asked question in scn blog.  Just SAP replied that saying i can use SAP Backend system in  "Destination"

thanks

Sharif.

Former Member
0 Kudos

Dear Stephen,

We are planning to go for staged DB for Orgmodeler.

But I am unable to find recommended size info for OrgModeler Stage DB configuration, i meant size info for installing Stage DB.

thanks

Sharif.

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

Actually you don't have a choice of whether to go for a staged database for OrgModeler - you have to have a database in which to store your modelling scenarios.

The last capacity planning guide for VSN was released with 4.0 (or at least I'm not aware of the release of any others since then) - it should apply across all subsequent versions until such time as Nakisa release an updated version.  This guide contains details about database sizing.

The recommendation from Nakisa is as follows:

  1. Find out the data set sizes for HRP1000, HRP1001 and HRP1001 in your source system.
    • Use transaction code RE_RHDBST00 to get the required memory (in kb) for each of the tables.
  2. Total up the results.
  3. Double that total and that's your recommended size for your database.

If you want to future proof it even more, you can use the number of records shown in RE_RHDBST00 to give you an approximate memory requirement per row, then estimate what size your tables are going to grow to and scale your result from there in a similar manner.  You can of course also set the usual auto-expansion options, increase the base size by an arbitrary/estimated amount, etc.

Regards,

Stephen.

StephenMillard
Active Contributor
0 Kudos

Hi Sharif.

Terminology can often muddy the waters when discussing databases - I always have to be doubly careful when discussing the details with DBAs.

Starting at the highest level, you have the type of database (e.g. SQL Server, Oracle), then you have instances of the (DBMS) database management system (you can install multiple SQL Server instances on one server instance for example), within each instance you can have multiple databases and in some cases multiple table spaces within a database can also become a factor.  Within these you can then have multiple schemas (logical collections of database resources such as tables, views, constraints, etc.) and user accounts may be able to access one or more schema within a database.

The VSN applications are typically set to use a single database user account to access a single database and typically the default schema for the user account being used such that the account has enough privileges to carry out the required tasks (setting as the Database Owner is usually the most succinct way to ensure this).

I dare say that you could create a user account to produce a schema alongside your ECC schema in your database, but then that would be an extra hurdle or level of complexity in setting-up backup routines.  by creating a separate database (it could be in the same DBMS instance), you segregate the data making it cleaner in terms of setting up backups, system management and also general administration - e.g. you could take down the new database without impacting the ECC database.

It's been a few years since I was looking after databases and their licensing, but at that time database licensing was typically on a per user of the DBMS or a per CPU basis.  I expect there are probably even more options now as licensing rarely seems to get simpler over time.  However I would be surprised if there was a financial difference between the two options.

In terms of the computational resources and overheads I would suggest that for most servers running enterprise level database systems this would be minimal - we're not talking massive databases here.  For those where this would be an issue I would expect that capacity planning would already be looking at addressing the fact that the server was running so close to its limits.

For the reasons outlined above (and I'm sure several more if I gave it some more thought) I would always recommend a separate database for a VSN application.  Depending upon the modules I guess I might recommend a single database for multiple VSN applications (but always with separate schemas to avoid discrepancies incurred in overwriting data and structures in identically named tables between modules), but probably only where the data was limited.  e.g. storing user preferences for a TeamManager installation in a separate schema alongside an OrgChart schema in a single database.

I don't know how that compares or fits with the response you received from SAP, but hopefully it gives you enough insight to make an informed decision for your organisation or client.

Regards,

Stephen.

Former Member
0 Kudos

Hi stephen

Thanks for your detailed information.  can you please clarify the below as well.

If i am installing a separate Oracle DB for Orgmodeler, should i create the database manually or OrgModeler will create, after i enter the User Credentials in Orgmodeler Admin console.

StephenMillard
Active Contributor
0 Kudos

Sharif.


Someone needs to create the database.  OrgModeler cannot, would not and really should not do this.

Whilst OrgModeler can create table structures, views, indexes, etc., it cannot create the database itself as the credentials you supply would be for the database/schema, not for the database management system.  Therefore it would have no initial access to carry out the creation operation.

Similarly whilst it could in theory derive some of the information about your organisation via a connection to SAP (for the purposes of sizing), it wouldn't be able to auto select the correct parameters for configuring the database that your database administrator would select based on an organisation's database management policies, etc.  In order to do that, Nakisa would effectively have to code all that stuff into OrgModeler each of the database types and versions and then maintain that.  There's simply no benefit when a DBA should have access to a familiar tool/client already designed to enable exactly that.

Does that make sense?

Regards,

Stephen.

Former Member
0 Kudos

Hi Stephen,

Do we required separate license for Stage Database(If users are created.) or its part of Nakisa licensing.

Thanks

Sharif

StephenMillard
Active Contributor
0 Kudos

Nakisa licensing is for Nakisa software only.  They do not licence your choice of third party database - you need to do that separately.  This gives you the best option to match into any existing database licensing agreements.

Regards,

Stephen.

Answers (0)