Object Librarian

Jgsepulveda

Active Member
Hello All:
I hope you can help me... I have tried JDE, but still waiting...
This is what I'm doing and what I need:

I created a separate pathcode and environment to install Update6. I followed all the instructions from JDE (including the creation of a separate Data Dictionary), and everything went smooth, but as time goes, we discovered that we need to have a Separate Object Librarian. I have been trying to create a Second Object Librarian for Update 6 only, but nobody really know how to do it.
When I tried R98403 using the OL as the Datasources, it only copied 1/3 of the records of F9861. I can use SQL, but I don't feel is the right answer... for now.

Any idea how can I create a Second Object Librarian?
Thank you
 
Why do you create a second object librarian? The systems asks you where your object librarian tables are - just use your DS for Object Librarian - B7333.
I did it in austria without any problems.
Regards

Herbert
 
Hi,

You don't need another Object Librarian -- You need to add Object Librarian records. You have to ran the R989861 -- Processing Options Target and Source Path Code.

Try it.
 
Basically speaking, idea of creating a separate Object librarian data-source (at least F9860 table) for ‘Updated’ environments might not be as mad as it appears.

Even if we create a separate ‘Data Dictionary’ datasource for the environment where Update (or ESU) is supposed to be installed , there is still one (at least) common point for all environments that can be affected. This is a F9860 (Object Librarian master) table.

When Update/ESU is applied, OneWorld can modify definition of the existing object in F9860. The most dangerous point is a BFLOCN (Business Function Location) field. Occasionally JDE changes properties of some business functions from ‘Client/Server’ to ‘Client only’ or ‘Server only’ and vice-versa.

Even if Update/ESU is applied only to one environment (let’s say DV7333), definition of the business function is changed across the board because of F9860 is shared by everything.
In case ‘Business Function Location’ was changed to ‘Client only’ for let’s say function Bxxx1, Bxxx1 will not be included into the any future full server package in ANY environment.

The same time, some business functions in PY7333 environment will still have references to the Bxxx1. Therefore, server package for the PY7333 will fail, since Bxxx1 was not copied to the server during package build (it was marked as a ‘client only’).

In worst-case scenario, full PY server package will be built successfully (let’s say there are no references to the Bxxx1).
But, in case of W* environments where functions are mapped to the server by default, all calls to Bxxx1 will fail, and users in WPY7333 (WPD7333 etc..) will start getting errors after applying full PY7333 package to the server. Chronologically this may happen weeks or even months after applying update to the DV environment, and the reason of the new issue will not be always obvious.

Real examples (XU1->XU7):
1) Properties of B9861101 where set to ‘client only’. PY server package build failed after applying XU7 to DV.
2) Properties of N98305 where set to ‘client only’. PY package built went through fine, but users in WPY environment started getting issues with Data Selection. Eventually we had to map N98305 locally for all environments.


Ok, It’s time to finish this long post …..

Of course, I don’t think that it will make a lot of sense to create a separate instance of F9860 in real life (this would be a violation of all possible JDE rules :) , but it’s always a good idea to remember, that there is a some risk for all environments even if Updates/ESU is applied only to one ‘super-dedicated-segregated’ environment.

Regards


Yaroslav
 
Well, Yaroslav made a lot of good points. Not to mention that was like reading my list of issues, but I went through and I was abled to managed them... it's not easy, but it can be done.

Now, the main reason for the separate OL for XU6 is this:
1. We are still doing custom development and changes to JDE objects in the set of production pathcodes... (yes I know, we should not make modifications to JDE objects... but this is real life.. sorry)

2. As this is JDE and ESUs are needed.... since our set of production pathcodes are OneWorld Xe Base, we have been forced by some issues to install ESUs that have common objects to XU6.

3. As to promote a ESU from one Pathcode to another, the project need to hold the token, I been forced to choose from one project or the other. As I don't want to break XU6 or any of the ESUs we have applied either, in the Production Pathcode or in the XU6 pathcode is went the need for a separate OL was born.

I was told by JDE today it can be done, that I need to use a TC or SQL to make the cleaning in F9861.... but as usual, as this is not standard... is not supported.... :)

The main concern was the management nightmare of multiple pathcodes, DD and OL. I have to agree, but I do really think the result will pay itself.

I will keep you post of the new developments and thank you for the feedback.
 
Back
Top