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,

[Dr Atul G- LNG]

Glad to know my experience helped here. Please close this thread by accepting the solution. @Mi1 

[Mi1]

Hi Atul,

Thank you for your continuous support throughout this thread. Your initial guidance helped me stay focused on OOB principles while finding a way to meet my complex requirements without AppEngine.

The discussion with you and Adrian has given me the confidence to move forward with a sustainable and scalable design.

Best regards,

[Dr Atul G- LNG]

Good to know mate. You can multiple answers as solutions and if you think and comfortable that my answer also helped you.

[Adrian Ubeda]

Hi @Mi1 , 

Map your custom functionality and see how it suits with REQ-RITM-SCTASK. I recommend you not to modify directly anything OOTB, if you need to create anything, just duplicate and edit but always have an OOTB version to compare. Apart form that, create your scope and functionality need it over there and then use global objects, create cross scope access between applications for avoiding errors and problems. 

[Mi1]

Hi @Adrian Ubeda ,

Thank you for the detailed advice.

The method you provided seems very helpful for the initial request flow.

I have a question regarding reporting and data maintenance. Since we have a 40-table limit, I am considering using one "Generic Ledger Table" to store the latest status of various services post-approval.

Do you think this "Generic Ledger" approach is better for reporting compared to pulling reports directly from RITM variables?

I am worried that relying solely on variables might make complex reporting difficult in the long run.

Any advice on this architectural choice would be great.