Service action and re-deployment of consumers
Application Type
Traditional Web
Platform Version
11.11.3 (Build 29602)

Hi all,

I have a (service) module with a service action to retrieve menu items for a dynamic menu. Used by different applications in our platform (specifically designed not to have to release all application if something is added). The Module contains a structure that is used in the service action output. Called MenuItems. If i look in servicecenter at the dependencies i also see this:


THe name contains a 2 because in the specific consumer module an item with that name already existed:


WHen i deploy (lifetime) the gocommonshared through our deployment street i sometimes get a "redeploy dependent applications" which contains this consumer. SO it actually wants to redeploy the consumer. But the Structure and Service action in question do not change. Seeing this is a weak dependency we do not understand why this redeploy's the consumers if the functionality they use was not touched. 

Trouble lies in the fact that deployment WITH these redeploy's takes an hour in stead of 3 minutes (lots of consumers) and also might trigger timers set to go after deployment (not entirely sure about this)...


Could anyone enlighten me?

Have you verified that no circular dependencies have been introduced within the architecture of your application model? Circular dependency may impose you to redeploy outdated consumers.

Also, are there any changes in the parameters of your service actions? A change in parameter information, even name or data type, will require an update to consumers.


Cheers
Emman

No circular dependencies...Only dependencies in the SA module are towards the underlying CS module and system. CS module only has dependencies downward as well..


As to the parameters: This structure and accompanying method in the SA module have not been changed for a while :




mvp_badge
MVP

Hi Alexander,

Why would you want to have UI related logic in a service module, and expose data through a service action? This seems unnecessarily overcomplicated and also not performant (service action = REST API).

Regards,

Daniel


Hi Daniël,


This menu system has a lot of logic in it that works with our SSO and our (Single) role provider. Both of which are external to outsystems. We host some 100 applications of which 20 applications use this centralized menu structure. A component that leads to a UX-layer component which is identical in each of the front-ends. Making a central component that has a strong dependency leads to a lot of redeploy's when deploying the component. We centralize a bit more than just the menu structure (for instance notifications, release notes, several selectors etc...) in this application to not have different common applications. The development in this component is however not continuous, but comes in bursts when we add functionality. Or when something changes with the calls to external systems (which happens also due to the external systems being developed as well). 

Working with service actions has led to a significant decrease in deployment times and different teams waiting on each other to finish to be able to deploy changes in this centralized application. The REST part is exactly what we were looking for. Loosely coupled etc... One point of entry for data and logic(!) relating to these subjects. 

As to the performance part. The menu's are cached and are lightning-fast. Our user base is only about 4000 with a max concurrency of app. 900. This has not led to any issues up till now (even on test environments).

As to the UI logic: This is not just UI logic, it handles the SSO and Role Provider logic as well (the coupling of the OS roles to our centralized roles managed by a totally different department). 

But as mentioned: The REST part also seems a bit to tied-in sometimes. I can not really pinpoint when it happens, but changes that are NOT done in this functionality DO sometimes trigger re-deploy's. The only solution i can come up with is to spit the SA module into different SA modules within the applications. So as to not have to change it when we add functionality. Trouble there is that for instance the release notes are tied to menu items. As are the notifications.  So we like the disclosure of the logic to be concentrated in the same module (of course logic itself is in Core Services layer and connections underlying integrations layer). But the SA methopds sort of belong to each other (at least some) functionally.

Hope this explains a bit.

Tx for reading,

Alexander

mvp_badge
MVP
Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.