Any issue with using the same LN company number in different Infor OS instances that publish to the datalake?

Hello.  Let say we have 2 different Infor OS instances/Tenants -- Development and Production.

In Development, I establish company 175, and publish data tied to that company 175 to the datalake.

In Production, I need to eventually publish that same data.  Is it ok to have the same company number, 175, in this other Tenant? Is it best practice to keep the same company number in this example for datalake operations?  Any pitfalls?


From what I can tell reading the ION guide and reviewing the sql scripts that are part of the Service_ion.sqlscripts package, there is a Tenant ID that will delineate this data.  I won't be able to accidentally get development AND production data in the same data lake query or flow.  The 2 tenants' data are isolated from each other unless you do some sort of specific tenant-to-tenant config.  It seems like you would probably want the company number to be the same between dev and prod if you have company specific configurations tied to that number that you are replicating?  


Thanks for any assistance you can provide!

  • Hey  

    There's no issue here at all. Your development and production tenants are effectively two different "instances" of Data Lake. There would be no issue with company 175 existing in both instances since they are basically two separate environments.

    Any data that goes into the Data Lake is inherently firewalled to be accessible only to the applications, systems, and users within that tenant eco-system. You can send the same exact file, with the same exact data to the Data Lake in both tenants but querying them returns data from each respective file.

    With respect to best practices, that's left to you on how you manage your development datasets.

    You're also right on with your last paragraph. Unless you were to establish connectivity from one tenant to the other through the use of APIs or alternative configuration, then one tenant would never be exposed to or otherwise entitled to access the data of another tenant.

  • In reply to Mike Kalinowski:

    Thanks Mike, appreciate the fast response! That answered it.