E9.2 UDO management and promotion

[JohnDanter2]

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]

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!

 

[JohnDanter2]

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

 

[Larry_Jones]

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

 

[BOster]

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.

 

[JohnDanter2]

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

 

[JohnDanter2]

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

 

[JohnDanter2]

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]

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]

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.

 

[JohnDanter2]

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

 

[JohnDanter2]

Sorry to bring this up again but I am more familiar with the 3 levels of UDO security now.

I just want to know, can you make the UDO Action Security in PROD different to the UDO Action Security in DV PY UT for example (As E1 says this then global)

I want users to create UDOs and request them to be published, but I do not then want them creating UDOs in PROD. As if they can, they will.
Even if just personal UDOs, they can still cause harm with performance etc

Thanks

John

 

[DSauve]

You would need to set up a separate set of UDO security table(s) in PROD and set up the appropriate OCM mappings to point to correct set of tables.

 

[TFZ]

Or you can get fancy and create a role that's only for DV/PY that grants the access difference you want. I don't think I've ever tried UDO security wise, but Im just blindly assuming that action security on a UDO works the same. So make *PUBLIC the more restrictive, create a new role called UDODEV or something, and grant it environments DV/PY, and then give it the expanded action security.

Now that I type that - I should probably try it...

 

[JohnDanter2]

Thanks guys

Both ideas have been floating about. The separate role maybe the easier one. Allow a non PD role the ability to do as they want in DV PY UT only. Then restrict PD access by not allowing that role to sign into PD.
I'll insist on a specialist role that will allow PD changes, just incase there is a mistake and a quick change needed

 

[JohnDanter2]

Final question

I see in OMW web that the OMW projects you create cannot have a mix of object types, whatever the first object type added is, governs the type of OMW.

So with that in mind, lets say I needed to code some logic into P48013 and this was added to a traditional F98220 OMW project, could I then also create several UDOs over P48013 and then add them to a OMW Web project at the same time?

So, the base E1 APPL in one OMW and the UDOs over the same APPL in a web OMW

Thanks

John

 

[MFreitag]

Final question

I see in OMW web that the OMW projects you create cannot have a mix of object types, whatever the first object type added is, governs the type of OMW.

So with that in mind, lets say I needed to code some logic into P48013 and this was added to a traditional F98220 OMW project, could I then also create several UDOs over P48013 and then add them to a OMW Web project at the same time?

So, the base E1 APPL in one OMW and the UDOs over the same APPL in a web OMW

Thanks

John

Of course - why not? I have customers who work with Attachments that tell us (CNC) if there are dependent OMW projects that need to be transferred or belong together e.g.

 

[JohnDanter2]

Hi again lads

I wanted to ask you your processes on how you grant individual security to UDO types up through then ENVs.

I ask as I've just amended a page and added 3 new watchlists, I can't see them. The reason is I now need to ask my CNC team to grant me access to the 3 new UDOs
Our CNC team wants us to create an ISR ticket for EVERY new UDO created. Which I think is a bit overkill and not very user friendly.

So I wanted to know, how are you guys managing the 'security' and publishing side of UDOs as I don't create an ISR ticket for every new ER type E1 object I make. I just make it and promote it. Not sure why we think UDOs should be any different

Thanks

John

 

[DSauve]

With a watchlist there is also an underlying Advanced Query - another UDO that has to be shared and have security applied. So your 3 watchlists actually result in 6 UDO's (the 3 watchlists plus the 3 advanced queries). Hopefully you you can convince your CNC team to bundle them together in a single ticket to simplify ticket administration (both for you and them).