2 E1 instances - one Next Number table

BOster

BOster

Legendary Poster
We are going to be installing a completely separate instance of E1 (same tools release level). However, we have a need for some of the next numbers to be unique across both instances, specifically address book numbers, but possibly others as well.

As a proof of concept I was able to mod the Address Book MBF (actually I modded GetAndValidateAddressBookNumber) to get AN8 next numbers for instance B from instance A's NN table by making an interop call to X0010GetNextNumber from instance B to instance A, so we know we can do it that way. However, we have also kicked around the idea of using table OCM mappings to map the next number table (tables ?????) in instance B to instance A so that all next numbers are unique across both E1 instances. Oracle has stated that theoretically this should work although they hinted it may require mapping more than just the F0002 table.

Anyone have any thoughts on this? Has anyone done anything like this?
 
They may be hinting at the next numbers by company and fiscal year table. Even if you are not currently using the feature, you never know when a business user might start.

Next number like values come from the banking table as well for the next check number.
 
Brian,

Using the OCM mapping would be the way I would do this. I would also store the NN tables separately to the normal CTL and DTA. In oracle database speak, this would be in a different schema/owner (not necessarily a different database). I haven't had much to do with MSSQL so I'm not sure what the equivalent would be.
 
Thanks for the input. I think we have decided to go the OCM route and map all the NN tables in both instances to one datasource. According to Oracle and a CNC consultant this has been done, only instead of two separate instances it was multiple environments running on a single instance. Since our tools release will be the same in both of our JDE instances, this is effectively the same thing.

Oh, and we are adding a second JDE instance to an existing JDE instance, so we really don't want to change the database schema on the NN tables in the existing instance. All though, I am curious why you recommended that.
 
Brian,

[ QUOTE ]
I would also store the NN tables separately to the normal CTL and DTA

[/ QUOTE ]

[ QUOTE ]
I am curious why you recommended that.

[/ QUOTE ]

This may be an expression of, what some would call, my conservative nature. Also, our DBAs like keeping things separate. However my reasoning is along the lines of limiting any cross connectivity. As the entire data source (schema) would be shared between the two instances, a separate one would be defined for the NN tables, thus limiting the tables that can be shared. It prevents possible access (via accidental? OCM mapping) to other tables that are not supposed to be shared. As you are now using another environment in the same JDE instance, the protection that separation affords is substantially negated as all data sources are defined and available to all environments within the instance. However, with someone new looking at your setup, it would be a heads up, from the database point of view, that it is not operating as a standard installation.

I hope that is clear and not too confusing.
 
[ QUOTE ]

I hope that is clear and not too confusing.

[/ QUOTE ]

Very clear and makes a lot of sense. If we were building both instances at the same time instead of adding a new instance to an existing one I would think we would strongly consider doing as you suggested.
 
Hi Boster,
We are also planning to seriously test this option of sharing NN across instances (F0002 & F00022). I saw this thread on JDE list by you and it seems you did almost the same.

1. Oracle supports but does not recommend this approach. However, the amount of efforts it will save us during our future Instance consolidation plans makes it compelling for us to consider this option as our first choice.
2. If you actually implemented this can you let me know pls if you had any issues in using this in practice and came across any problems which made you think in hindsight that you should not have taken this approach or done something differently?
3. If everything worked well for you so far (hope it has) then what are the other precautions or take care things that you would suggest based on your experience.

We have one 8.0 instance and we are now implementing one new 9.0 instance (A). In future after the 8.0 is upgraded to 9.0 (B), we plan to merge the two 9.0 instances (a+b).
To avoid future complications and NN issues, we are exploring the idea of sharing NN tables F0002 & F00022.

Thanks in advance for some quick inputs pls.
 
Boster,

Would you share your experiences with sharing next number tables across two environments?

Thank you
K
 
Back
Top