Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Semantic Modeler vs. Model Administration Tool in OAS 2025 Migration

Accepted answer
110
Views
9
Comments

Hello Oracle Community,

We are currently planning our migration from OAS 2024 to OAS 2025 and are evaluating the use of Semantic Modeler versus continuing to use the Model Administration Tool for managing our RPD/Semantic layer.

Could you please provide some insights on the differences between these two tools and help us understand the pros and cons of using one over the other? Specifically, we would like to understand:

  1. Key Differences: What are the main differences between Semantic Modeler and Model Administration Tool in the context of OAS 2025? How do these differences affect usability, functionality, and model management?
  2. Pros and Cons: What are the advantages and potential drawbacks of using Semantic Modeler compared to the Model Administration Tool? Which tool provides better performance, flexibility, and ease of use?
  3. Customer Experiences: For those who have already adopted Semantic Modeler in OAS 2025, how has the transition been? Have you faced any challenges or found any significant improvements compared to using the Model Administration Tool?
  4. Future-Proofing: Considering the evolving nature of Oracle Analytics, which tool is likely to be more sustainable and better supported in the long run? Should we plan to transition to Semantic Modeler as part of our OAS 2025 migration?

Any guidance or shared experiences from customers who have already worked with these tools would be greatly appreciated!

Thank you!

Tagged:

Best Answers

  • Hi,

    The real answers would depend on what feature you use in the Model Admin tool when developing your RPD.

    Keeping it short: the Semantic Modeler is going to be the future and, at some point, the Model Admin tool will disappear.

    If you use the various tools in the Model Admin tool, you will not find those in the Semantic Modeler. On the other hand the Semantic Modeler has a native git integration, making it extremely simple to version your models and to work in multiple people using git for merging etc.

    For the model itself, both do the same things because they both produce the exact same file to deploy on the server.

    Because you aren't starting from scratch but already have a RPD, you first need to import it in the Semantic Modeler and see if it is imported correctly (sometimes it does fail). Then it's a different user experience: if you are used to the Model Admin tool, you will need some time to adjust to the Semantic Modeler and develop new automatism in how you work. The Semantic Modeler requires more clicks, because it's web-based. But you more easily can modify the json defining the model for mass updates or changes.

    While technically possible, you should avoid keep jumping from one to the other: decide which tool you are going to use based on your internal processes and stick to it. If you switch to the Semantic Modeler, you should consider adopting versioning in git and evolve your process to be based on that.

    It's difficult to talk about "improvements", it all depends on how you use the tools: some users will see the Semantic Modeler as an improvement, others will miss too much a tool (like the rename wizard) and will not be able to use Semantic Modeler for now because it's missing.

    You must try it and decide by yourself, that's the only way to decide if the Semantic Modeler is good enough for your needs and processes, or if you have to wait another iteration.

  • @Gianni Ceresa has great observations here.

    You may also consider a two-step process here. Migration to OAS 2025 first. Once that is fully migrated, then work on the transition to Semantic Modeler as a second step. This will eliminate any concern over OAS differenced verses the modeling tool. As Gianni indicates — the underlying RPD is the same. So it is mostly about new web-based tooling with git integration. I do recommend moving to git as part of the process as this is one of the biggest benefits.

Answers