OI10 RDK issue

BarryStevens

I am trying to determine where this issue lies as I am not sure how the Deployment RDK works.

In OI9 in DEALER account I create an RDK view via the OI Deploy
Then in SRP Editor I open a proc from Account PBC and add it (F6) to the DEALER RDK view.
Then I create the deployment RDK file.

In OI9 all is good

In OI10 I do the same thing but the deployment puts the PBC one in DEALER
Is this an issue with how you add to the rdk view, or, with OI10 creating the deployment because I dont know how the account is determined as I dont see it in the RDK view on either version.


I just need to get my facts straight before I re-report it to Rev.

DonBakke

I take it that DEALER is the child application you are currently logged into and PBC is the parent application where the entities are stored?

You can answer your own question by creating the same RDK in OI 10 strictly using the built-in RDK tool. For my own testing, I created two identical Repository Views. One with the SRP Editor and one with the built-in tool. I then deployed both. In both deployments I am seeing the same problem. This suggests to me that this is an OI 10 specific problem. I suggest you do the same thing, or at the very least create an RDK using only the built-in tool, and pick entities from the local and parent application. Deploy and see what the file contains.

I've often wondered how the extraction tool knows which application to pull from. When I look at the Repository View records, there is nothing in them that identifies where a specific entity comes from. My guess is that in OI 9, it crawls through the inheritance chain and preserves the name of the entity as it finds it whereas OI 10 always assumes you are deploying into the local application.

KevinFournier

I'll have to investigate this. I know that the SRP Editor simply adds the entity with it's original app directly to the view, but perhaps OI 10 is doing some kind of sanity check I don't know about when I write it.

KevinFournier

Actually, can you open the SYSREPOSVIEWS records in each environment and confirm whether or not they have the correct app?

KevinFournier

Sorry, I shouldn't be doing this so late. I thought you were seeing if this was an SRP Editor issue. I see now that you posted in this in the OpenInsight forum.

This is definitely an OI 10 issue. When you look at the SYSREPOSVIEWS record, you'll see that entities never include app information. Only the entity names. When OI deploys the RDK, it should be finding the entity in the highest most app in the inheritance hierarchy. I assume ATTACH_PBC_DATABASE doesn't exist in DEALER, so OI 9 finds it in PBC. I'd expect OI 10 to do the same, so this is an issue of OI 10 deployment providing unexpected results. I'd ask Revelation about this.

BarryStevens

Cool, thanks. That was the only way I could think it would work.
I will check that, by some mishap, that there is no ATTACH_PBC_DATABASE in DEALER

BarryStevens

all good there.
I will add the to the tracker as that might be an obvious question they might ask.

AusMarkB

Obviously, I could test for myself but maybe you have the answer already Barry.
What happens in either OI9 or 10 if you are in the child app DEALER and you use the F6 to add a routine from the parent app PBC, but a version of that routine also exists in DEALER.

You want to include the parent app version even though there is a modified version in the child app.

No, I don't know why you would want to do that, but you've sparked my curiosity. :)

Actually, I do know. Maybe you've made the same change to both because it applies across the board so now you need to deploy both. Can you deploy both in the same deployment?

DonBakke

@AusMarkB I suspect not. As I pointed out, Repository Views do not add an application identifier for each entity. Therefore, when a Repository View is extracted, the logic has no way to determine which version of the entity you intend to deploy. Thus, it goes for the version that is closest to the local app and then crawls up the inheritance chain until it finds a version of the entity.

AusMarkB

@DonBakke, that makes sense.

Means I for one, need to be more cautious when using the F6 option. Sometimes I deploy out of a child app just because it's the one I'm currently logged into. In theory, that means that I may unintentionally deploy a child app version when I think I'm deploying the one from the parent app.

Probably never happen but good to be conscious of.

DonBakke

@AusMarkB technically the problem is not using F6 versus the RDK tool itself. The problem is being logged into the child application when you create the Repository View since that is the application you'll be deploying from. Remember, you can add inherited entities from the RDK tool as well.

I want stress that this is a deployment problem. If you deploy from a parent application then you'll get the parent version of that entity.

AusMarkB

Oh, I get that it's a deployment problem and I'm not throwing any shade on the F6. In fact, the primary reason I use it is for this purpose; to add routines from the parent app because I've changed them whilst testing in the child app.

I'll admit, I'd forgotten there was an "Entities in Current Application" checkbox in the repository view. It's always checked by default, so my brain's been programmed to think it is limited to the current application.
That said, it doesn't quite present the same problem. Regardless of how many applications have a copy of the same routine, it only appears once in the list. In other words, it presents itself as belonging to the application you're in. That then makes sense of how the deployment works.

The very minimal risk you face with using the editor is that you open the parent version because that's the one you need to change. Work on it for a while. Sometime later, you make the deployment and add it, forgetting that there is a modified version in your current application. I would add it here primarily because it is still open in the editor and that serves as the reminder it needs to be deployed.

If I was using the rdk tool as the reminder, I'd be using the "Entities changed since" option in one application and then again in the other application, in a separate repository view.

Probably all just a procedure and habit issue rather than anything else.

The reality is, I don't believe it's ever happened so the likelihood is probably miniscule but I'm theorising out loud.

BarryStevens

"Entities in Current Application"

Never seen that work - unchecked (implied all applications)

DonBakke

@BarryStevens - Are you saying you've tried that before and it never worked? If so, do you mean it never displayed inherited entities or it never deployed the inherited entities you selected?

BarryStevens

If so, do you mean it never displayed inherited entities

Yes!

DonBakke

Interesting. It has worked for me for as long as I can remember:


Not only do I see inherited entities when I uncheck the box, I see entity types that only exist in the inherited app.

BarryStevens

Oh, OK, now I see it working as you are showing me.

I must have missed something when I was looking (hope I was clicking the 'all Application Entries' again - ooops)

Thank you, so I will remove that from the back of my mind.

Probably what I though was confirming my suspicions was that the F6 was there to 'Fix that (supposedly) issue'

Thanks, so all good now - nothing to see here - (except inherited entities 😜 )

BarryStevens

@KevinFournier

Looks like RDKVIEW is formatted differently and the ACCOUNT is now being stored as well - see field 16

Maybe you need to check-up on this.
Green is the OI10 RDK created one. Red is what F6 added from PBC account.

(Yes, I know, Dog with a bone)

DonBakke

@BarryStevens - yes, that is a difference but I don't think it deploys any differently. You need to deploy and check the SYSUPGRADE table like I suggested previously.

BarryStevens

Yes it does, as I said in my first post - the PBC one ATTACH_PBC_DATABASE deploys to the DEALER account.

I might see if I edit that record and add PBC*ATTACH_PBC_DATABASE..... to <15> and <16> , create the deployment and see what it then creates.

BarryStevens

Nope - well that definitely is an issue. So, the beta issue post still stands.

DonBakke

So, the beta issue post still stands.

Can you point me to where you posted this? I can't seem to find it.

DonBakke

Yes it does, as I said in my first post - the PBC one ATTACH_PBC_DATABASE deploys to the DEALER account.

I think we are talking past each other. I meant that in OI 10, whether or not fields 15 and 16 are populated, it deploys the same. Would you agree?

BarryStevens

Agree, yes?. Just wanted to test that theory.
Issue 125