UBE Version Data Selection Overwritten On Enterprise Server

JDEList,

I recently encountered a problem where the data selection for UBE version was apparently overwritten on the enterprise server. After some investigation, I found that this was the case.

When a UBE version is run on the server from a client (not triggered on the server itself by a scheduler - JDE or other), the data selection for the version is overwritten.

This what happened: I ran a UBE version from a client and changed the data selection at the time of running the version. Report came out as I expected. Then the same UBE version was run by a scheduler on the server. I had expected it to use the original data selection, but it used the changed data selection that I had used when I ran it. I then looked at the data selection from a client and it was unchanged (note: to change the data selection on a version permanently you need to check it out in OMW, change it, and check it back in, then install it). I than ran it without changing it and it was as expected. I then manually ran the UBE version on the server (using runube) and it was as expected - it had changed back to the original data selection.

I monitored the tam files - the rdaspec.ddb and rdaspec.xdb in the spec directory - and they were indeed updated.

This is different behaviour to what happens if a UBE version is run locally - when the data selection is changed when submitting the UBE version loaclly it is not changed permanently, only for that run.

I was not aware that the behaviour on the server was different to that on a client and I am guessing that I am not alone in this, so here is a "heads up". This appears to be operating as designed and is probably the same for other JDE versions.

My installation config is:
Oracle JD Edwards EnterpriseOne,
E8.11sp1 8.97.2.1, ES Sun, Oracle DB 9207, Websphere 6 Win2K3.

Yes, this is indeed one from the "normal" and "as designed" category ;-)

Normal.

Check this out to prevent it from happening inadvertently:

http://jeffstevenson.karamazovgroup.com/2009/12/data-selection-security-in.html

[ QUOTE ]
Normal.

Check this out to prevent it from happening inadvertently:

http://jeffstevenson.karamazovgroup.com/2009/12/data-selection-security-in.html

[/ QUOTE ]

This will work with 8.98 tools release. For 8.97 and below you can define separate schedular batch versions and set the security on these versions during design as 2 or 3.

... Doesn't seem normal, or maybe I just don't run enough reports....

If I understood...

When the Scheduler ran the job, the DataSelection:
GBCO = '00010'

Original Data Selection on a Version is:
GBCO = '00010'

You submitted a job from a 'client' (developer or web??) as:
GBCO = '00020'

When the Scheduler ran the job, next, the DataSelection is:
GBCO = '00020'

To confirm - you ran the report, you didn't just 'submit specs'?

Often, I override the DataSelection for Change In Progress and submit the spec. I haven't noticed that Changing the DataSelection on the Fat Client, then Submitting has ever updated the DS for Version on the server...

Am I not taking enough meds?

(db)

Daniel,

As stated by others , this is the "normal" behavior by design. Not saying it’s a good design

When the OW scheduler runs a job on an enterprise server (same would the case if you manually ran runube or runubexml from command line on the ES), it uses the runtime specs on the Enterprise Server.

The key here really is to seperate out your scheduler versions and manual versions. It is not a good practice to share them.

When ever you submit a batch version (from web or FAT) , it always submits "with specs" , you can see this in your jde.log. The "specs" in this case will be what ever runtime selection you make.

User submissions are not affected, because each user starts the screen with original data selection defined on the version and then makes changes if needed and it will overwrite what is on the server.

The scheduler will pick up the specs as on the server.

I have had to deal with this kind of issue a lot and the only way I could avoid this completely was to have separate versions. Of course now that the Data Selection security is available it makes it easier. The fix if it has already happened is to do a "submit spec only' for that version (Worked only from the Web for me , for some reason , doing a spec only submit from FAT would not overrite the specs on the server)

If you really want to look at this under the covers here is a small exercise you could do using the runubexml command. It generates an xml file that lists the spec of a version (Data selection) as on the Batch server

For steps on how to use the runubexml command refer to this post # - 154766

1 Generate the runubexml file for a version on the batch server

2 Now run this same batch version from Web or Fat , but change the DS. Remove some lines , add some lines etc

3. Do step 1 again. (Important to name the file differently)

Compare the two files . You will see the first file has the DS as per the version's definition

The second file will have the DS as per the manual submission you did.

If you were to run that same version from the scheduler now it would use the DS as per your last submission.

Very 'Normal' since B7332 when I climbed on board, we have separate version s for Operations specifically because of this...

From: [email protected] [mailto:[email protected]] On B ehalf Of peterbruce
Sent: Thursday, February 11, 2010 10:20 PM
To: [email protected]
Subject: UBE Version Data Selection Overwritten On Enterprise Server

JDEList,

I recently encountered a problem where the data selection for UBE version w as apparently overwritten on the enterprise server. After some investigatio n, I found that this was the case.

When a UBE version is run on the server from a client (not triggered on the server itself by a scheduler - JDE or other), the data selection for the v ersion is overwritten.

This what happened: I ran a UBE version from a client and changed the data selection at the time of running the version. Report came out as I expected . Then the same UBE version was run by a scheduler on the server. I had exp ected it to use the original data selection, but it used the changed data s election that I had used when I ran it. I then looked at the data selection from a client and it was unchanged (note: to change the data selection on a version permanently you need to check it out in OMW, change it, and check it back in, then install it). I than ran it without changing it and it was as expected. I then manually ran the UBE version on the server (using runu be) and it was as expected - it had changed back to the original data selec tion.

I monitored the tam files - the rdaspec.ddb and rdaspec.xdb in the spec dir ectory - and they were indeed updated.

This is different behaviour to what happens if a UBE version is run locally - when the data selection is changed when submitting the UBE version loacl ly it is not changed permanently, only for that run.

I was not aware that the behaviour on the server was different to that on a client and I am guessing that I am not alone in this, so here is a "heads up". This appears to be operating as designed and is probably the same for other JDE versions.

My installation config is:
Oracle JD Edwards EnterpriseOne,
E8.11sp1 8.97.2.1, ES Sun, Oracle DB 9207, Websphere 6 Win2K3.

Thanks, Peter Oracle JD Edwards EnterpriseOne, E8.11sp1 8.97.2.1, ES Sun, O racle DB 9207, Websphere 6 Win2K3. Forms: Create!form Server 3/Server 6

Jeff,

[ QUOTE ]
Normal.

Check this out to prevent it from happening inadvertently:

http://jeffstevenson.karamazovgroup.com/2009/12/data-selection-security-in.html



[/ QUOTE ]

Thanks for the information on data selection security available from TR 8.98. It will be useful when we upgrade - no plans at the moment, maybe in 2011.

We usually do as Joel, ice_cube210 and Darrell advise, separate versions for the scheduler and UBE's run via runube. However, they have never been secured intentionally to isolate these versions, the versions aren't on any menus etc. and some of them are actually secured for other reasons.

Daniel,

[ QUOTE ]
Am I not taking enough meds?


[/ QUOTE ]

I did thoroughly and carefully test this before posting. May be you need additional medication.



In the case which brought this to my attention, which is a custom UBE, I was actually investigating some data that was missing from the results of the last run of the UBE on the scheduler and ran the UBE/version from a client, changing the data selection to include only the missing data. (The results were correct, and I discovered a change had been made during the intervening time that corrected the situation.) However, when the UBE version was next run on the scheduler only the previously missing data was in the results. I then tested things as described in my original post.

I have recommended securing all the versions used in this way. However in the instance where this was discovered, there has been a push from within my organisation to replicate the UBE functionality using a Stored Database Procedure (originally they wanted a SQL query, but the functionality is too complex) - my opinion on this is that, for the instance under review, it is like using a large sledge hammer to swat an ant, and for other cases, impractical or (effectively) impossible.

Thanks to all whom replied.