How to develop using RITM without using AppEngine

[Mi1]

Hi,

I want to create an application based on RITM.
Until now, we have been developing using App Engine, but this time we need to re-implement the services within the ITSM package(RITM)  without using App Engine.
Do you have any suggestions for implementing what was created in App Engine within the ITSM(RITM)?

Also, please let me know if there are any things to be careful about or any limitations that may arise.

Best Regards,

<------------- add information --------------- >

Thank you for the suggestions.

To clarify my requirements and get more specific advice, please let me add a few points:

1. Table Limit:

We have a strict limit on the number of custom tables (currently 40), which is why we are shifting from App Engine to an RITM-based architecture.

2. "Ledger" Management:

In App Engine, we managed the "current state" (e.g., active user permissions or asset status) in custom tables. RITM is an audit trail of a "request," but I need a way to manage data that remains "living" after the RITM is closed (e.g., updating a completion date or expiration date later by a fulfiller).

3. Data Segregation:

The application will be used by different departments (HR, IT, General Affairs). I need to ensure that sensitive data (especially HR-related) is strictly restricted to specific groups via ACLs, even though all records reside in the same RITM table.

My specific questions are:

• For managing the "current state" after a request is closed, do you recommend using a single "Generic Ledger Table" to aggregate data from various items? Or is it better to manage everything within RITM variables?

• Are there any best practices for implementing robust ACLs on the RITM table to segregate data between completely different departments?

• What are the reporting limitations when using RITM variables instead of actual table columns for long-term data management?

I would appreciate your expert insights on these architectural points.

Best Regards,

[Adrian Ubeda]

Hello @Mi1 , 

Based on my experience, from an End user perspective using variables for reporting it's quite complex and some time investing is needed  (change management) for being able to be done by their own. However using a generic ledger table can increase really fast, for that (maybe) you will need to plan an strategy rotation for that table only.
Based on my experience, I'll go for the second one because it's going to be transparent for end user and can be managed in technical way which, at least from my point of view, easier than handle change management.

[Mi1]

Hi @Adrian Ubeda

Thank you for your very insightful feedback based on your experience.

It is very encouraging to hear that you support the "Generic Ledger" approach over the "Variables-only" reporting. I completely agree that managing technical complexity (like Table Rotation) is far more predictable and easier than handling the Change Management/Education required for end-users to navigate Variable reporting.

To address the growth of the generic table as you mentioned:
I am planning to implement a "Table Rotation" or "Archiving Strategy" once the volume reaches a certain threshold. My goal is to keep the "Active" records searchable for end-users while offloading legacy data.

One quick follow-up question:
In your experience, when using a generic table for multiple different services, do you prefer using "Generic Fields" (String 1, Date 1, etc.) to maximize reusability, or do you create unique fields for each major service despite the 40-table limitation context?

Thank you again for your support of this architectural direction!

Best Regards,

[Adrian Ubeda · Accepted solution]

Really like the approach related to table rotation and archiving strategy, this would help performance and improve UX.

Related to the question, in one hand; it depends (as always), generic fields would be useful in the technical way and so abstract and scalable, however in terms of reporting could be quiet complex to guess what you are looking at. Maybe you can cover this using database view. Having your main reporting and the rest of the fields as a support fields (just brainstorming).

In the other hand, I've seen a massive table in one client with creating unique fields for each process or need, obviously this it's not good in terms of best practices but they prefer one macro-table with everything needed that many tables accomplish best creation field practice.
If possible, I'll create abstract fields and try to reuse then and scale as possible.

[Mi1]

Hi @Adrian Ubeda 

Thank you for the additional insights. The concept of "Database View" to bridge the gap between "technical abstraction (Generic Fields)" and "business reporting (User-friendly labels)" is a game-changer for my architecture.

It solves our 40-table limitation while keeping the end-user experience high. I will proceed with this approach—building a robust generic ledger and using Database Views to present specific data to different departments.

I really appreciate your practical advice based on your experience with macro-tables and best practices. I’m marking your post as the solution.

Best regards,

[Ankur Bawiskar]

@Mi1 

Sorry your question is not clear.