Multiple Object Librarian Databases - Good or Bad ?

Someone I work with is pushing for separate OL databases for our 4 pathcodes: 2 pathcodes in one OL and 2 in the other. I have worked on many different E1 installs and I have never wanted or needed or was requested to have multiple OL's. Oracle doesnt support it. I have my own opinions about this but I would like to get the List's expert opinion.

So the question is: Multiple OL databases - bad or good?

Without knowing the reason I would say bad idea, however, what is this person's reason to want this? Are the development paths between the path codes that would be separated included in the same promotion cycle anywhere? If so then I would definitely say bad idea.

I am not sure why that would be needed. The whole point of OL is to keep centralized repository of different objects in various Path Codes.

Having two different OLs means that you’ll have to have totally independent sets of Path codes without any promotions between them. I can not think of scenario why that would be needed (although you’ll never know …)

Having separate Data Dictionaries is quite common. Separate set of security tables – possible. Having separate OLs is really unique. Let us know how it goes!

They want it so that 1 bsfn can be tied to 1 dll in prod and the same bsfn be tied to another dll in dev.

Same development cycle.

[ QUOTE ]
I am not sure why that would be needed. The whole point of OL is to keep centralized repository of different objects in various Path Codes.

[/ QUOTE ]

Agreed.

I think that it will be more work and nearly impossible to verify that OL for PD gets update on promotions from DV.

[ QUOTE ]
They want it so that 1 bsfn can be tied to 1 dll in prod and the same bsfn be tied to another dll in dev.

Same development cycle.

[/ QUOTE ]

I've seen this request before - but who cares what DLL the custom business function is in ? Thats not a justification - its an excuse. Its ridiculous having a different OL for DV and PD - in effect, you're out of step immediately, and you'll never be able to sync or promote between DV and PD again. Stupid, stupid idea.

The problem is that its hard to explain to management why its a bad idea, when they think they know better (with no experience in the JDE system) - and often, the result is that the decision then gets made to do what the business wants, and 2-3 years later, the system is a mess.

Create a copy of the business function and replicate the changes between them - having one developer doing twice the work on one business function is NOTHING like having to replicate the object librarian twice and keeping all the objects in sync.

I've seen companies have two production pathcodes for different parts of the business, often for "localization" or for functional requirements. Again, completely not needed and often this can be achieved just by having multiple similar objects kept somewhat in sync by the development staff.

Don't have two object librarians. Reduce the pathcodes to what you absolutely, minimally need and your development cycle won't take months for objects to be promoted to production. Try to move outside of the recommended lines, and you'll end up with a world of hurt - trying to sync objects in the future (ready for upgrades or ESU's for example). Believe me, I know several companies that took this route and their management is now claiming their "unupgradeable".....(which of course they're not, its just a lot of work to upgrade them !)

I know - I'm the fish that might go upstream, against all the fishes that are floating downstream....

Having a completely 'separate' Installation for PRODUCTION - can be a good idea (some organizations 'should' require it). If you have a completely separate installation - you don't have to worry about Development fupahs, like: DD Changes, "OOPS Did I Delete that File", Updating the wrong pathcode, conversion screw-ups.... and MANY more. If Developers and Testers CANNOT get to the Production system - just call it Safe and Secure from them.

The fight against - is, usually, "More Work". I see that as a lame excuse. Protection of Productions - that should be Job One!

(db)

I think you have stated very clearly my sentiments as well.

Thanks for your expert opinion.

Sorry Danny, but I've gotta side with Jon on this one. If the developers can't be trusted, then fire them. I totally can not see the justification.

- Gregg

Sorry Gregory / Jonathan,

Other than lazy CNC folk, that don't like to work an extra couple hours a day - I haven't been able to figure out the justification for the lack of Protection to Production



Developers, Vendors, Newbies and ... CFO/CIO/CEO types - are each a reason to have complete separation. Heck, I even know a couple CNCs that didn't realize that DD changes were global....

(db)

Sorry DB.

We CNC's just exceeded a 24 hour day

Tom

Actually there is a rare situation when separate OL would have been (purely theoretically) helpful.

I have seen it couple times when particular ESU changes location for specific Business Function from 'Client/Server' to 'Client only'
This information is stored in OL table F9860 (field SIBFLOCN) ONE record per object.

Applying ESU only to DV will change BSFN property for ALL environments.

This could easily create issues with business function build in PD package. Client only BFs are excluded from server build, but old code in PD could still looking for particular BF while building server part of the package.

Therefore applying ESU to DV can unexpectedly cause issues in PD.


This probably could have been fixed by changing OL tables design, so 'Location' information is stored in F9861 instead of F9860. I guess its too much to ask from Oracle : )

I still wouldnt even think about 2nd OL to prevent such issues. Its not worth it in my opinion

Dan,

We have two JDE installations (separate Enterprise Servers, Deployment Servers, Web Servers, Dtabase Servers and Admin/development Clients) one for production (one environment, thus one pathcode and one database) and one for test/development (four environments, four pathcodes, five databases - one for each pathcode and one for system wide tables). However, I keep them in synch. As far as CNC time/effort goes, we are basically a one man JDE shop - me. We don't have a great amount of development. If I haven't the time for it, we outsource it. I am rarely required to work long hours.

Now as to the reason for this, it is a policy of the organisation for which I work to keep production and test/development systems separate. There are a number of advantages to this: system wide changes can be tested without effecting production (eg security); processing intensive tasks can be done without bring production to it's knees; Access to production is not possible for outsourced resources. Changes/updates to machine hardware and operating systems can be tested first before being done in production. Even highly trusted, highly competent, highly skilled people can make mistakes.

Granted, these things do not happen all the time, but they do happen and having separate production and test/development installations allow them to happen, without effecting production.

However, we do not use multiple OLs in the one installation of JDE.

Hi,

I understand and agree that we should separate Production
DBs, App servers, Web Servers, even DDs and security
tables from DV/PY ones, but I don't see the advantage
of splitting OL.

If that were the case...

How would you promote objects from PY to PD?

By creating an ESU? Or replicating the whole pathcode?

Why would you think that's safer than promoting "as usual"
via OMW?

Why not setup a proper security scenario on the
OMW promotion process?

Finally, separating OLs won't protect you from
poor development or QA practices. Both of them may
be way more destructive than having a single OL.

Sebastian has the greatest insight!

Multiple Object Librarians - Good/Bad idea; that was the original questions. Sorry - I turned it into a 'separate machine' argument, which doesn't really apply to the question.

If the 'reason' for separate OLs is because a function needs to be pointed to different DLLs - then it is better to code the function 'correctly' so it identifies the environment it is run from and correctly directs itself to the appropriate 'pathcode-based' DLL.

I'm guessing that this is a custom solution or a third-party solution - that is being addressed. If your Functions needs to point to a specific process, based on the environment/pathcode - then; "Don't Fix Something that is Already Working - Correct that which is the exception."

It is not extremely difficult to point to a specific 'something', based on a pathcode.
* E1 files, use OCM (base solution)
* For Targeted issues, consider a PO Template
a) Create a PO Template with a Long String Variable
b) Within the Function/Application/UBE - Grab the values for the PO - and now you know where to pull objects from. This solution allows you to have different options/setup per environment
c) Allows you to configure 'handles' per environment, also. You could setup an enormous amount of flexibility

Going back to original issue - Fix the code that is calling, rather than fix something that is already working.

Two pennies are in the mail.

(db)

[ QUOTE ]
I'm guessing that this is a custom solution or a third-party solution - that is being addressed

[/ QUOTE ]

Basically YES, a custom solution has been developed. The developer created a BSFN and assigned it to the Standard JDE DLL called CALLBSFN. After the BSFN is already promoted to PD, the project leader tells the developer to move the BSFN to a DLL called CCUSTOM. That change is made and so the BSFN actually is moved to CCUSTOM in DV and left in CALLBSFN in production. So, because of the way JDECallObject works, in production it starts to fail because the function hasnt been promoted up to production yet and built into CCUSTOM. JDECallObject looks for the bsfn based on the parent DLL field in F9860. So the call to this BSFN blow up.

Then the idea strikes somebody that there should be 2 F9860s (two object libarians). I personally cant see how it would work because I dont think there is a way to specify which OL data source you are using by pathcode.

Let's see if I understand the issue:
1 - Develop creates a Function - pointing to CALLBFSN
2 - Function gets deployed all the way to Production
3 - PM finds out about CALLBSFN and requires change to CCUSTOM
4 - 'someone' uses SQL to update the functions internal description to point to CCUSTOM
5 - The function is redeployed in DV and works fine.
6 - The function is CRASHING in Production

Right?

So - why not promote and redeploy? Alternately, shouldn't a Full Build resolve the issue (a full build will re-build all the DLLs and place the logic within the 'new/corrected' DLLs.

Someone slap me with a mag-light, but... shouldn't a full build, without any promotions at all - resolve the issue?

Did I miss something?

(db)

Even a rebuild of the said function alone in an update package in PD should build it into the right DLL.

Just have to make sure that the JDEBLC spec is also in sync , there is a doc somewhere on KG to do this.

If they only rebuild the 'update' - doesn't that leave the remnants of the original build in CALLBSFN?

Logically, I would expect the old code to linger in the original destination - until a full build is complete.

Thus, my preference would be a full build - just to clean out the previous destination.

Does someone need to slam the Mag-Light at me a bit harder?

(db)

Yes function will still be in CALLBSFN dll also until a full build is done

But from a runtime perspective on the Enterprise server once the update package has been built and deployed , the function should be available under CCUSTOM also and that should solve their runtime errors I would think

Long term fix definitely a full package. If time is a constraint , a short term solution of an update package should also fix the issue.