Web Only Maintenance Packs available with tools 9.1.5.4

ice_cube210

VIP Member
For any of you that haven't come across this already , Oracle has introduced Web Only maintenance packs that will allow you to quickly update the Tools release on your JAS / AIS server components , without having to update the other components ( Server Manager , Dep Server , Enterprise Server etc) , as long as they are all on the same base tools release , ie 9.1.5.x

So if you recently upgraded to tools 9.1.5.2 say and just finished testing , and you are interested in some fixes available in tools 9.1.5.4 that address UI issues or browser issues , you can apply 9.1.5.4 to your JAS servers , while keeping the rest of your components on 9.1.5.2

Read these two docs on the support site for more details

Now Available! New Delivery Schedule for Web Only Maintenance Packs (Doc ID 2014092.1)

JD Edwards EnterpriseOne Tools Web Only Maintenance Packs Frequently Asked Questions (FAQ) (Doc ID 1997531.1)
 

BOster

Legendary Poster
If I understand correctly in the FAQ it says that the local web dev client would NOT be in sync with the JAS servers. Is that correct? If that is true, I feel like that pretty much makes this a useless feature.

We currently have an issue that is clearly TR related and specifically JAS server related. Furthermore the error is reproducible on both the JAS server and the local web dev client. If we were to apply a Web Only Maintenance pack that fixed this issue it would mean that our local web dev clients would be behaving differently than our JAS servers. This means that what you would see/debug on the local web dev client may not be the same as what is happening on the JAS servers. Welcome back to Xe Fat/JAS client hell.
 

altquark

Legendary Poster
That is correct. The "web only maintenance pack" seems to be for those customers with minimal development requirements that do not want to go through and update the tools release for Batch processing and other components in their enterprise. I'd have to also point out that supporting this from Oracles' perspective is also going to be a nightmare - resulting in architecture that might not be fully supported because they cannot replicate an issue due to so many different tools release version differences. I'm not sure this is a good thing - I totally recommend that customers do not create differences between their configurations that the majority of customers utilize - I don't like implementing POC's unless totally necessary for the same reason, and that customers have a good plan to keep their tools release current as much as possible.
 

RussellCodlin

Reputable Poster
The web only maintenance packs would be in response to the POC's that Oracle has had to provide for their web gui in between the usual tools updates. There are always plenty of little javascript and JSP fixes in each tools and this will allow them to release multiple minor tools updates to address those without having to go through the usual full cycle for a new tools dot release. It also helps with their MVP approach to new features like AIS or ADF components.
 

BOster

Legendary Poster
I am fine with the concept, it just feel like it was only half way implemented. Why not provide a solution that updates the JAS server as well as the local web dev client so that a developer can be confident that what he is seeing when he is developing an application is what he is going to get once it is deployed on the jas server?

What happens when someone applies one of these and all of a sudden something that worked on the local web dev doesn't work on the JAS server? Now we are back to:

1. blindly make a code change locally that we think might fix the problem
2. check in, build a package and deploy
3. Did that fix it? No. Lather rinse repeat.

This is very similar to what we had to deal with back in the Xe days between fat and jas clients when something worked locally running on the fat client but didn't work on the JAS server. It was very slow, tedious and frustrating.

I rather have a POC that I can apply to both the JAS server and local web dev.
 

RussellCodlin

Reputable Poster
What happens when someone applies one of these and all of a sudden something that worked on the local web dev doesn't work on the JAS server? Now we are back to:

1. blindly make a code change locally that we think might fix the problem
2. check in, build a package and deploy
3. Did that fix it? No. Lather rinse repeat.

This is very similar to what we had to deal with back in the Xe days between fat and jas clients when something worked locally running on the fat client but didn't work on the JAS server. It was very slow, tedious and frustrating.

I rather have a POC that I can apply to both the JAS server and local web dev.

I don't think it is the same thing. To start with they are still doing full quarterly tools, you just get little tools in between. Secondly, JAS works in a completely different fashion to the way it worked in the XE days. Back then you were generating full java objects from TAM specs to generate the web application components whereas now it is just an interpretation of XML specs that is done on the fly. So in the scenario you're talking about you would need to have a JAS issue that you could code around in FDA before the package build would come into it seeing as a package build now has nothing to do with the JAS server. Even in that scenario it would have to be a bug that is in the newest JAS only tools but not in the base tools you're running on the deployment server with your local web dev environment.

You can also add to this that the local web dev environment is not an exact match to the JAS instances now so it is already possible to have issues on one that you can't replicate on the other as another reason why not having the web dev and JAS server perfectly in sync is not that big a deal.

I suspect one outcome we will see out of this is faster increments of the tools number. What I mean by this is we'll get from 9.1.5.x to 9.1.6.x a lot sooner because as soon as there is an issue that affects both the enterprise server and the JAS server then they'll need to increment the minor version so that dependencies are understood.
 
Top