Show "Used in Page" reference in Modules Settings

fabien.junod · November 2023

Any update on this? It seems all the information is already available in the model under "Pages".

Now it's "only" a matter of showing it under the "modules" section

kjacokes · November 2023

eager for an update on this as well!

Ari · November 2023

Hi, yes please this information is very useful and the relationship exists in the model:

Page uses —> Module

We would need rather:

Module used in —> Pages

Line item used in —> Pages

The later is much more useful to understand dependencies when updating the model, otherwise you have to look page by page is if you were doing it from the front end.

Thank you

Hvbarata · April 5

Any update on this.

This is definitely something that would be very useful in the models I'm working on right now.

I can't even see the solution posted by @fabien.junod in November. I'm investigating if this could be something related with User Security, or if the feature was discontinued since November.

kjacokes · April 5

When this crossed my inbox this morning I thought about this a bit more.

My guess is that this is a bit of a lift and they’re working on it. A bit of a lift for a few reasons.

Reason 1:

Space Considerations

Anaplan’s core modeling features run on a single machine or part thereof. App pages, CloudWorks content, etc is all stored outside of that machine. Architecturally speaking Anaplan wants to preserve as much of that server’s memory for modeling workspace, so it’s not trivial to allocate incremental non-cell memory to something outside of allocable workspace, like storing text names/IDs of app pages associated with modules in the core. That could be 1000 module names/IDs x 1000 page names/IDs across 100s of apps or more, meaning potentially gigabytes of extra relationship data to be stored someplace. I could be wrong but depending on the EERD of the data model this could mean rearchitecting a part of the UX<>Model data model, so I could see this requiring measure and cautious steps from Anaplan.

Reason 2:

Platform Performance Considerations

I suspect the engineering team is working out:

-when a page is published, if there are 100 modules referenced, go to some table, and update that table to add that app page to the list of pages that the module is associated with…today that processing only has to happen when an app page is published or loaded…what we’re asking for would require that every time a model is opened we search for every app page it’s on, which could be changing constantly, and that feels like a lot of network and I/O traffic to be happening on the Anaplan core that isn’t happening today

-be able to do this at scale…because whenever you create or update or delete pages or modules, it’s a CRUD action:..at platform scale that’s costly and potentially degrades performance for a very common task

-something that took some time to get right was solid performance of the communication between the app layer and the Anaplan core (model)…I imagine and hope they're testing this to ensure we don’t see this enhancement degrade performance somehow

-the benefit provided exists but maybe has a perceived ROI that is less than other enhancements

All that’s to say my guess is this will get some love, but it make take some time. All wild speculation on my part, mostly sharing to think through this out loud and on the off-chance I’m directionally correct it’ll help us appreciate the complexity of our ask.

Hope everyone’s doing well out there. Take care of yourselves, and if you can, someone else.

Cheers,

Kevin