WebDev feature not working after Full package on Windows 7 Fat Client

Bulldog

Active Member
Hi All

This is a perplexing issue and I was wondering if anyone on the forum has had to deal with this? A Developer fat client running 8.11 SP1 8.98.3.4 and on a windows 7 machine (I know what your thinking) with snapshot installed was working normally and running the Web Dev feature with no issues. A snapshot save was taken of this config and saved off. A new full PY811 package was then installed into the machine and suddenly the Web Dev feature no longer works and gives a "JAS error contact your administrator" when it tries to login. The JAS logs don't really tell me what the issue is and my thoughts are that the issue lies around permissions in the C:\\811 (and subdirectories) as the full package removes the 811 folder and gets windows to recreate it. Never had the issue when the machine was XP - only now when its Windows 7 and its foibles.

Does anyone have any idea as to how the new snapshot instance can be restored to get the Web Dev feature running again - I do have a working saved snapshot instance which runs the feature with no issues. Is there some comparison I can run between the two. What would be nice is a deep dive document on the full package installation. My instincts say permissions but I'm no Windows 7 admin so any help would be great. Just trying to understand how a full package kills the Web Dev stone dead? Update packages are fine, hence my question.

regards..
 
Hi Bulldog,

I've seen some issues pop up with this on some of our dev machines. Silly as it sounds make sure you've rebooted. Also, you may need to make sure to right click -> run as admin not just at this point, but perhaps when you try the installation of the package. If those don't work let me know, I feel like there was another weird case, I'd have to search harder for that old ticket....

Good luck,
Roy
 
Thanks Roy,

I've rebooted the machine and started JDE using the Run As Admin option. I can log into PY811 and JPY811 and access apps as normal. Its only when I try to run the local Web that I get the JAS error - contact your administrator. Its almost as though something in the full package is screwing up the access to local web. I even re0installed the Web Dev feature again to no avail,

regards..
 
Have you checked your jas.ini and jdbj.ini files in your local webdev client directory structure -- they're buried. Make sure these are pointing to correct pathcodes and use correct port numbers. While you're at it, check to make sure your JDE.INI on your webdev client is using the correct port, too.
 
Bulldog,

In the short term for the dev in question you can try swapping in the jas.ini, jdbj.ini and jde.ini from a working system.

Going forward you could try the multi-environment tool we are using to great effect, a simple set of scripts provided to us by Mid-Range when they were in helping us with some training. It eliminates the need for using snapshot altogether.

I've attached the folder structure they provided us, we just had to customize the scripts a bit, mostly for the version of JDE we are running. You'll also have to swap working versions of the three .ini files into the sub-folders for each environment. There are some extra environments in the folder they provided, we just set this up for DV/PY/PD. I've also attached most of the message (stripped out our server names etc) I'd sent out to our devs, I found the order of the steps (installing JDE, the webdev feature etc) to be a little tricky to sort out. Also, I placed our installation folder in the E900\...\ThirdPary folder on our deployment server.

I touched base with Mid-Range to make sure they were OK with me sharing this and they provided a good explanation of why the issue occurs and how this tool resolves it:
---
The problem with multiple path codes on a web dev client really lies in the fact that the ini files can only point to one local database (and one path code / environment), and even if the local web dev client appears to be working, he will be generating to the same database for both DV and PY and get some unexpected behaviour and not see his code changes, etc. He may have to manually reinstall the correct web dev package again (with run as admin like you said) but it sounds like he did that. One other option is to reinstall the DV full package with the web dev feature, but he'll need to reinstall all update packages or recompress the full package first. His jde.ini could have lost all the settings in the web dev section at the bottom. I'd compare that to a working DV web dev client.
---

It's a pretty simple concept, but I found it took me a while to get things working smoothly. Let me know if you're having any issues getting it set up and I'll help if I can.

Regards,
Roy
 

Attachments

  • MultiEnvironment.zip
    208 KB · Views: 44
Hi Roy,

much appreciated for your time and effort on this, the information is very helpful and I may yet look at employing this solution. We have two enterprise servers running separate instances of DV/PY/PD and therefore have Snapshot running so that we can switch between the two. I notice in your comms that you had tried Snapshot but it did not work out for you? My customer has switched to Windows vista for their VM development machines and still get the issues where WebDev does not work. We installed everything again including the full DV/PY package and verified that the Web Dev feature was working. When you take update packages all is fine, it's only when you take a new full package do you see the issues with Web Dev not working. I'm aware of the of the updates that happen to the classes folders and the ini files when you take a full package hence the use of Snapshot to ensure we are using the correct files but will look more at the JDE.ini files and the WebDev section and compare to running (good) DV install that has a working Web Dev feature. I think what I might do in the first instance is take a backup of all those files (including the Classes folder) and then install a new full package and then re-install the backups to see if this solves the problem as from what I can see your script seem to do this as they restore the original settings back in.

Once again thanks a lot for this - it's given me food for thought and with the scripts I can see what your trying (and have accomplished for that matter). If I need anything further I'll let you know but for now I think I have the tools to stop this error once and for all :)

regards,

Bulldog
 
Bulldog,

Glad you got something out of the info. The seperate instances probably makes things trickier, but sounds like you have some ideas on where to go with this. I'll keep an eye on the thread but in the meantime good luck!

Regards,
Roy
 
Roy,

I am curious to know how Midrange came to the conclusion that you can't use multiple webdev pathcodes without changing the INIs around. If your OCM is mapped properly, you set the Pathcodes to include all valid local pathcodes, and you omit spec file database settings in the .ini's, what is it that prevents the local JAS instance from using the properly configured OCMs to find serialize objects, etc.?

Can you cite a reference on Oracle support that says multiple pathcodes with webdev can't be supported?





Bulldog,

---
The problem with multiple path codes on a web dev client really lies in the fact that the ini files can only point to one local database (and one path code / environment), and even if the local web dev client appears to be working, he will be generating to the same database for both DV and PY and get some unexpected behaviour and not see his code changes, etc. He may have to manually reinstall the correct web dev package again (with run as admin like you said) but it sounds like he did that. One other option is to reinstall the DV full package with the web dev feature, but he'll need to reinstall all update packages or recompress the full package first. His jde.ini could have lost all the settings in the web dev section at the bottom. I'd compare that to a working DV web dev client.
---

It's a pretty simple concept, but I found it took me a while to get things working smoothly. Let me know if you're having any issues getting it set up and I'll help if I can.

Regards,
Roy
 
jdel,

A valid question. I'm sure there is a way to get snapshot to work, but we kept running into the issue of not being able to connect to both databases without swapping the .ini files. I can't imagine Oracle would say this is "the" way to do it, but we found this to be the easiest way.

Roy
 
No, just forgetting about Snapshot for 1 second.

If you have a single tools release on a given client, why would you need to swap around INI's per environment? If you have the INIs set properly, E1 is smart enough to know which OCMs to use (tables, logic, etc.) by environment so there would be no reason to make environment specific INI files.
 
No, just forgetting about Snapshot for 1 second.

If you have a single tools release on a given client, why would you need to swap around INI's per environment? If you have the INIs set properly, E1 is smart enough to know which OCMs to use (tables, logic, etc.) by environment so there would be no reason to make environment specific INI files.



The jde.ini, jas.ini, and jdbj.ini have entries which should point to local - xxxx. So if you log into DV900 fat client or JDV900 web dev client, it should connect to local - dv900.

JDBJ.ini for instance has the [JDBj-SPEC DATA SOURCE] stanza which should point to the correct local datasource for a given local web dev environment. Otherwise you will always connect to the same local web dev instance.

As for where Oracle specifically states multiple path codes not supported for web dev without snapshot, please see this doc all the way at the bottom:
E1: INST: How the Local Datasource Name in JDE.ini and JDBJ.ini of Web Development Client is Determined (Doc ID 867203.1)

Web Dev Setup for Multiple Path Codes

A Web Dev (or JAS instance) setup for multiple path codes is not supported. Therefore, it is important that each Web Dev install be specific to one and only one path code including its local data source.

If it is a requirement to have a Web Dev client on a single Workstation that supports multiple path codes, it is possible to use Snapshot to manage the web dev installs for multiple path codes.

Assuming that you are starting from a base state of no EnterpriseOne client being installed on a workstation, follow these steps:

Install the Fat client for a given path code.
Install the web dev feature for that path code.
Use Snapshot to save off the installed client with the web dev feature.
Repeat steps 1-3 for each additional path code where the web dev feature is required.
Use Snapshot to switch between the web dev clients installed for each specific path code.

The use of the Web Dev client with multiple path codes will require a separate set of client configuration files (JDE.INI, JAS.INI and JDBJ.INI) for each path code. Using Snapshot will make managing the configuration files a generally effortless process.
 
....
JDBJ.ini for instance has the [JDBj-SPEC DATA SOURCE] stanza which should point to the correct local datasource for a given local web dev environment. Otherwise you will always connect to the same local web dev instance.

As for where Oracle specifically states multiple path codes not supported for web dev without snapshot, please see this doc all the way at the bottom:
E1: INST: How the Local Datasource Name in JDE.ini and JDBJ.ini of Web Development Client is Determined (Doc ID 867203.1)

Web Dev Setup for Multiple Path Codes

A Web Dev (or JAS instance) setup for multiple path codes is not supported. Therefore, it is important that each Web Dev install be specific to one and only one path code including its local data source.

If it is a requirement to have a Web Dev client on a single Workstation that supports multiple path codes, it is possible to use Snapshot to manage the web dev installs for multiple path codes.
....

For starters, I think you might want to note a couple of things:
1. Those tech bulletin references are horribly out of date (at least 10 years old).
2. The tech bulletin that you are quoting describes what happens to INI files and registry entries for webdev when a package is deployed. It doesn't specifically mention what happens at runtime.
3. Have you ever tried omitting the values for Spec Data source in the jas.ini and jdbj.ini? I think you'd be surprise what happens especially if you create OCM mappings for the serialized object tables.
4. Oracle doesn't support VMWare. Do you suppose VMWare is not being used by E1 customers?
5. Snapshot doesn't handle the local JAS integration with WebSphere when you swap between foundations. Does that mean you cannot run multiple pathcodes with a WebSphere local web dev?

I would be curious to know if you have ever worked with any of the older tools releases. It was not uncommon to have multiple pathcodes on as single JAS instance (and it was specifically supported and documented to work this way).
 
Not really interested in getting into a back and forth here. You asked about where Oracle stated not supported and I simply provided that. Sorry if it's out dated.

Note, when you omit the spec data source, then it uses your OCM and will actually connect to the F989998/9 that the environment you sign into uses. I suppose that you could set your fat client environments to access the local web dev tables via OCM but then you wouldn't be accessing the same environment as your HTML (J) environments. If you sign into a J environment on your web dev, then I assume you have your J environment web dev tables mapped to central objects. This means that you connect to the same F989998/9 tables that your html environment uses so you could actually make changes to your dev client that would be generated directly to your HTML web environment. Not such a big deal in Dev but maybe not the greatest idea in Prod. By placing the local values there, you then connect to your local F989998/9 and can make any changes you wish without effecting everybody connecting to the HTML instance tables. It also gives you the flexibility to change those values on the fly.

Just my 2 cents. Really, there are many different ways to skin the JDE cat so do whatever works for you.
 
I think basically what you are saying in a long winded way, is that you agree with me about not neeing to copy INI files. The Oracle doc you cite doesn't actually say it doesn't work, it just says that they won't support it (naturally because of the complexity).

To summarize and paraphrase what you said: if you omit the spec data source and specify OCM mappings it will use the local F989998/9 and local DLLs. The primary reason you run the non-J environments on the dev client is to debug the code. The local OCM-mapped serialized objects just facilitate that. The other jdbj.ini, jas.ini and jdbj.ini don't really serve any other purpose besides supplying port numbers. And, if you set services up right, your port numbers don't need to change.
 
Last edited:
Yes, that is what I was getting at, sorry for the rigmarole. I think some people prefer changing INI files because they may be restricted from making OCM changes outright without procedures, tickets, approvals etc so it's easier to just change local ini files or use snapshot, etc. It's usually just the path of least resistance to change local ini files. I typically use a batch script to handle wherever I go.

Thanks for responding jdel6654.
 
Back
Top