Multi-level architecture and outdated consumers

Multi-level architecture and outdated consumers

  
I've seen the presentation notes done here entitled "The Art of Designing OutSystems Architectures": http://www.outsystems.com/nextstep/presentations/

The notes by Francisco are really helpful in that they gave me a much clearer idea of a decent separation of data, utility functions, front end forms etc.

The presentation stresses that there should be no dependencies upwards, which I understand. However, I'm struggling with the practicality of the situation where you may have two eSpaces in a particular layer that each refer to each other - for example, two data services modules. Every time one is published, the other shows as an outdated consumer, so it doesn't seem possible to get both of them to show as having up to date references.

Am I missing the point, or is it impossible to have two eSpaces with references to one another, without getting the "outdated consumer" messages?

Also, I would have expected that publishing an eSpace would only cause consumers to show as outdated if the external interface of the eSpace had changed - if there are no changes, or purely internal changes, surely the consumer shouldn't need updating? Why does the outdated consumer message appear when nothing's changed?
Hello Iain,

My thoughs about it:

Iain Fogg wrote:
Am I missing the point, or is it impossible to have two eSpaces with references to one another, without getting the "outdated consumer" messages?

If I'm correct the references to another eSpace always need to go just one way. So reference two eSpaces both ways would always causing 'outdated consumer'. If you need this the only way to prefent this is to make a solution with both eSpaces and publish the solution.


Iain Fogg wrote:
Also, I would have expected that publishing an eSpace would only cause consumers to show as outdated if the external interface of the eSpace had changed - if there are no changes, or purely internal changes, surely the consumer shouldn't need updating? Why does the outdated consumer message appear when nothing's changed?
 
Yes the consumers needs to be updated. You must see it as following, the consumers are references to the published eSpace (lets call it eSpace 1). When you publish a new version of eSpace 1, the references of the consumers are still to the previous version of eSpace 1. So you need to update the consumers so the references would be updated to the last published version of eSpace 1.

Hope thats clearfull enough?

Kind regards,
Evert
Thanks Evert. I didn't know publishing a solution would solve the problem, although I don't know if that will work for our structure or not.

With regard to the second point about updating consumers, I still don't see why a consumer needs to be republished if the external interface hasn't changed - if every public entity, action, parameter etc. is the same, the consumer will not be any different after the re-publish, so what's the point of a republish? I feel that the way it currently works causes a load of hassle with a re-publish in a low level utility module potentially causing dozens of republishes across the whole system, when none of them seem necessary, and none of them change the consumer eSpace at all.

The version numbers of the eSpaces should, in my opinion, not simply automatically upgrade on every publish, but rather, they should track changes to the external interface.

It all feels quite messy to me, and seems to fly in the face of the simple deployment that Outsystems offers when it's a single application. It seems that the theory of the multi-level architecture is not so simply worked out in practice.
Hello Iain,

To reply on your post:

Iain Fogg wrote:
Thanks Evert. I didn't know publishing a solution would solve the problem, although I don't know if that will work for our structure or not.

[....]

It all feels quite messy to me, and seems to fly in the face of the simple deployment that Outsystems offers when it's a single application. It seems that the theory of the multi-level architecture is not so simply worked out in practice.
 

When you set all you're needed eSpaces (and extensions) into one solution and publish that solution, all references will be set correctly (so there will be no outdated consumer). So yes by this you can work with multple eSpaces (since setting a newer version on production would be done by publishing a solution instead off all eSpaces).


Iain Fogg wrote:
With regard to the second point about updating consumers, I still don't see why a consumer needs to be republished if the external interface hasn't changed - if every public entity, action, parameter etc. is the same, the consumer will not be any different after the re-publish, so what's the point of a republish? I feel that the way it currently works causes a load of hassle with a re-publish in a low level utility module potentially causing dozens of republishes across the whole system, when none of them seem necessary, and none of them change the consumer eSpace at all.

The version numbers of the eSpaces should, in my opinion, not simply automatically upgrade on every publish, but rather, they should track changes to the external interface.
 
Think there is something to be said on this but keep in mind that it's only a warning ;-). You write that the warning would only need to be shown if any public attribute is changed but I think it's not really possible to keep this tracked. Even so if you change something in a public action you can change logic without changing the outputs. So if that logic is published the consumers are still references to the old logic. i though you could use F5 or F6 to publish the eSpace with all consumers.

About the version number I think it's normal since you're only can publish if something is changed.

Kind regards,
Evert


Thanks Evert, I was more proposing that the tracking / versioning around external interface should be changed in a future release, to simplify multi-level architecture, rather than trying to make it work with the current system.

F5 / F6 don't republish outdated consumers, it's a manual process as far as I can see, trying to figure out what relies on what - in a big system, this can be pretty tedious.

I'll look into the solution more, thanks for that idea.