E9.2 UDO management and promotion

johnd

Well Known Member
Hi list

We will soon be upgrading to 9.2 and my Dev manager is asking about the creation and promotion process of UDOs in 9.2, now that everyone with E1 access will be able to create various UDOs we will be moving away from the current practice where I am the sole 'E1 developer'

So a few questions on this :-
1) Am I right in thinking the UDOs, even though data based, still work just like any other OMW object in terms of eventual promotion to PD etc

2) If I am logged in to UT and create a UDO, where does it 'live' and do they follow the same DV PY UT PD process.

3) Do they always get created in DV??

4) As end users can create these UDOs, who in your organisation authorises the publishing and promotion of UDOs

5) Do you treat orchestrations differently to a watchlist for example?

Think that's it for now :)

Thanks

John
 

DSauve

Legendary Poster
John,
I have always recommended creating UDO's in DV and then follow the usual object promotion to PY, (UT in your case), and then to PD.
UDO's are created per pathcode. In your case, if you create them in your UT, they're created midway through the promotion path. You can set up special activity rules to move them back to DV, and then move them all the way through the usual promotion process. But why create extra work for yourself? Just have them created in DV and your life will be much simpler (at least for UDO's :).
Your organization controls who can create, publish and view UDO's. I have seen where all users have access to create grid formats and queries, but other UDO types are limited to BA's, power users or developers. For some UDO's you need to be very careful about who you grant access to create. For instance, the Enterprise Search could be ill-formed or searching on non-indexed fields, and could be a heavy hit on your database. E1 Pages provide access to run applications and UBE's, so those would make sense to keep under tighter control. Watchlists could have performance implications, especially if you have a lot of them (also, creating custom Watchlists requires that you be licensed for OneView Reporting Foundation).
So there's no one-size-fits-all approach, and you'll need to work with your IT, Security and user community to decide on which ones make sense to give access to and at what level. Don't let that keep you from using the functionality that comes with UDO's, though!
 

johnd

Well Known Member
Thanks mate.
You're raising points I'm trying to bring up with management yes :)
UT is used as the data in DV or UT is usually pants. I may suggest OCMs for them so they still use the path code but get that good data (too lazy to schedule updates)

Thanks again for the reply
 

BOster

Legendary Poster
Was about to post the same thing as Larry. Some UDOs are probably ok, but I wouldn't just give everything to everyone - "citizen developer" sounds good but concept and reality can be two different things. From our experience things like Orchestrator Studio is still a developer/technical tool... you need to know what you are doing as well as having solid development practices, naming conventions, etc. And its not just because something "won't work". I could easily zombie the BAT server Call Object Kernels if I wanted using nothing but Orchestrator Studio - i.e. you can crash JDE if you don't know what you are doing.
 

johnd

Well Known Member
Quite frankly giving all end users total control to create UDOs (with a few exceptions) is a recipe for disaster ... They'll screw things up pretty bad IMHO

100%
The example I gave was would you let me promote code straight into PD without any testing etc? No. Of course you wouldn't, and I have 20 yrs of E1 experience lol

So all I'm doing is looking for a set of guidelines to create and promote UDOs. I think I'll suggest to just do them in OMW and follow same guidelines as any other objects

Its just narrowing down the creation of them of them and where they can make them is proving tricky
 

johnd

Well Known Member
Was about to post the same thing as Larry. Some UDOs are probably ok, but I wouldn't just give everything to everyone - "citizen developer" sounds good but concept and reality can be two different things. From our experience things like Orchestrator Studio is still a developer/technical tool... you need to know what you are doing as well as having solid development practices, naming conventions, etc. And its not just because something "won't work". I could easily zombie the BAT server Call Object Kernels if I wanted using nothing but Orchestrator Studio - i.e. you can crash JDE if you don't know what you are doing.

Bingo. I've advised that Orch Studio is a separate 'thing' to most UDO creation in E1 thin

I think they like the concept of citizen developers and empowering the analysts. But yeah, it's not going to work without extensive training. Even then whats created needs to be vetted and tested by someone who does before they are published/promoted
 

johnd

Well Known Member
John,
..Your organization controls who can create, publish and view UDO's. I have seen where all users have access to create grid formats and queries, but other UDO types are limited to BA's, power users or developers.

Thanks for this. Do you happen to know how you do that? Or is it just as simple as allowing them the in screen E1 Thin UDO options only (queries, watchlists, record a process etc) and denying them access to the Orchestration Studio?

Thanks again
 

Larry_Jones

Legendary Poster
Here's the thing John.
Oracle says, with some justification, that we can reduce or eliminate a lot of customizations by use of UDOs.
I've done this where we've combined composite pages, queries and watchlists all linked together to perform a solution.
If a user is allowed to them modify/customize/replace those UDO components they can break the solution.
I personally don't want to spend my time tracking down an issue only to discover its a user mod/replacement which is why things aren't working anymore.
 

DSauve

Legendary Poster
John,
To set this security up, from the P00950 security workbench, click on the form exit to User Defined Object -> Action. From here, you can grant/deny access by UDO type with access levels of Create; Create and Publish; Create, Publish and Modify; and Disable Create, Publish and Modify.
 

johnd

Well Known Member
Legends! The three of you.

I agree on this whole citizen developer thing. I struggle as it is to get basic info like APPL name, form name and version in helpdesk tickets lol.
It will be a lot worse and complex with guessing if there is a UDO on top I'd imagine
 
Top