Data Selection Changes via Web Client

I came across something new today. A user with proper permissions changed the version data selection permanently in the specs . I always knew that processing options values could be changed permanently. I did not know that DS could be permanently changed. How long has this been true? Seems like a major change control problem.

I have not been paying very close attention to the nuances of web versions (pre 8.98) and versions via web client so maybe this was documented at one time.

This has been there since long. You can lock the data selection.
But you can laways control thru version control & security what user can do and what he can't.

Chan

Chana,

Thank you so much for your contribution.

When you say for a long time, how long do you mean ? Was it available in tools 8.98.x ?

What is the purpose of checking-out & OMW if you can change it when you submit the UBE?

We have been using the web client under E1 9.0 and now 9.1 with different tools releases on both and have never seen the data selection get permanently changed. It always defaults back to what we deployed.

Dave Rammer
Sheboygan County
E1 9.1 with Tools Release 9.1.3, SQL 2008 on Windows 2008 server, E1 running on Windows 2008 server and we have two WebLogic servers running Windows 2008 server one internal and one for external

Yes what you are seeing is correct.

If you take the row exit "Data Selection" from batch versions and make a change to data selection , it will "stick".

This is different from choosing Data Selection during the runtime submission of a version , those changes hold good only for that submission and they do not permanently update.

I am not sure when this was introduced but it is certainly something that is recent, but I think as new (or old) as 8.98 and apps 9.0

Since the functionality did not exist before I see no reason why users should have it now and it is very confusing to them as they may not realize the difference between doing it from the row exit (permanent change) vs during submission (runtime change only).

So I simply secure that row exit using Exit security from *PUBLIC. They will still be able to make run time data selection changes like they did before

thanks for the clarification, I was not aware of this. It is secured out now

[ QUOTE ]
Chana,

Thank you so much for your contribution.

When you say for a long time, how long do you mean ? Was it available in tools 8.98.x ?

What is the purpose of checking-out & OMW if you can change it when you submit the UBE?

[/ QUOTE ]


Take a look at this:

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

Ice,

I did a little testing. Firstly the web version of the Batch Versions App (P98305W) and the fat client version (P98305) work differently. The web version allows you to update the data selection using the data selection row exit, depending on security and the fat client only allows you to update the data selection using the data selection row exit if the version is checked out.

Secondly, the web updated data selection only exists in the "serialised objects" table F989999. It does not update the data selection on the enterprise server (unless it is run on the enterprise server) or the deployment server.

Hi Peter ,

Thanks for sharing your findings. I was aware of the difference in behavior between the Web and FAT BV Application. But I had not dug deeper on the web update so I did and here is what I found

When you do a row exit data selection change from the web , it does update the central objects also (versions table in this case). As a simple test , change the data selection from the web using the row exit and then do a GET (from the same path code as the web environment where you performed the update) for that version on a FAT client , you will see the updated data selection.

You are correct that the runtime specs on the enterprise server are not updated , but the next time a full package or update (for that version) is done , it will get updated.

Also any users who run that same version from the Web will be running it with this new updated data selection

Thanks to everyone who contributed to this thread. Lot of good information.

My end-user thought she changed it on web submission, but as I test it more and more, it seems this was a change using the data selection button on batch versions (though she denies it).

What drives me nuts about this is 2 things: all the fine print on the rules with this and, second, the fact that this completely bypasses OMW (check-ins / check-outs).

The data selection security is an excellent tool if you can get your users to comply (ours won't).

I guess the only real solution is to apply the (1,2,&3's) to the F983051 version security.

When you do a row exit data selection change from the web , it does update the central objects also (versions table in this case).

I found similar results.

However, it looks to me like it updated the F98999*, F98761 & the F983051.

Yes that is what Peter found too regarding the F98999* tables. It makes sense that they would do that for what they are trying to achieve because other wise it would not reflect on the web for the next submission

You can secure this row exit and this way users can change data selection only when prompting the job to run and not make a permanent change.

We have had a problem regarding this surface over the past week.

Something I noticed in the ER behind the Data Selection row exit from P98305W (form A) is that it uses a new system function (Batch Versions) Set Selection Prompt.

Then I noticed and potentially more dangerous is the Data Sequencing row exit from P98305W (form A), if it acts the same way as the Data Selection. I suspect it does as it uses a new system function (Batch Versions) Set Sequence Prompt.

As our users have not been told about these row exits and one appears to have "stumbled across" it, it was quite easy to get agreement from the manager to lock both row exits off using Hyper Exit security in security workbench.

Yes, we noticed this as well. One of our senior analysts changed the data sequencing in a version. The net result was that the version became corrupted and/or the logic of the UBE was affected.

This is a very serious problem.