#microsoft50
Managed RAP
• Greenfield Implementation
• CRUD operations are handled by the framework.
• Transactional buffer is managed by the framework.
• The framework takes care of the save sequence.
Unmanaged RAP
• Brownfield Implementation
• CRUD requires custom implementation.
• Transactional buffer is managed with a global singleton/static class.
• Custom save sequence logic must be written.
Managed with Unmanaged Save:
• The interactive phase remains the same, but the save sequence is handled by the developer.
• Transactional buffer is managed by RAP architecture.
• No persistence table in unmanaged save.
Additional Save (Enhancing Managed RAP)
• Allows developers to implement additional steps for the save logic of a managed RAP BO,
enhancing the standard save sequence.
• Can have a persistence table, as the RAP framework takes care of persisting to the database.
Restrictions:
You can’t use a BAPI with a commit statement, as the RAP LUW takes care of commit and
rollback. Additionally, there’s no persistence table in Unmanaged Save, as the developer writes their
own logic for persisting. Please refer to the attachment for complete restrictions.
When using a function module (on-premise), always create a wrapper around it and
release it with C1 to maintain cloud compatibility.
Best Practices & Recommendations:
• Managed RAP with Unmanaged Save is often the recommended option, combining the best
of both approaches.
• Unmanaged RAP should usually be a last resort.
Key Use Cases:
• No Custom Code: Go for Managed RAP.
• Need to Utilise Update Function Module: opt for Managed RAP with Unmanaged Save.
• Reusable Code/Loose Coupling with Pre-existing Functionality: Choose Unmanaged
RAP.
• Consume Custom APIs (on-premise) in BTP: Use Custom Entities + Unmanaged RAP.
• Unmanaged Queries: Combine Custom Entities + Unmanaged RAP
Managed RAP• Greenfield Implementation• CRUD operations are handled by the framework.• Transactional buffer is managed by the framework.• The framework takes care of the save sequence.Unmanaged RAP• Brownfield Implementation• CRUD requires custom implementation.• Transactional buffer is managed with a global singleton/static class.• Custom save sequence logic must be written.Managed with Unmanaged Save:• The interactive phase remains the same, but the save sequence is handled by the developer.• Transactional buffer is managed by RAP architecture.• No persistence table in unmanaged save.Additional Save (Enhancing Managed RAP)• Allows developers to implement additional steps for the save logic of a managed RAP BO,enhancing the standard save sequence.• Can have a persistence table, as the RAP framework takes care of persisting to the database.Restrictions:You can’t use a BAPI with a commit statement, as the RAP LUW takes care of commit androllback. Additionally, there’s no persistence table in Unmanaged Save, as the developer writes theirown logic for persisting. Please refer to the attachment for complete restrictions.When using a function module (on-premise), always create a wrapper around it andrelease it with C1 to maintain cloud compatibility.Best Practices & Recommendations:• Managed RAP with Unmanaged Save is often the recommended option, combining the bestof both approaches.• Unmanaged RAP should usually be a last resort.Key Use Cases:• No Custom Code: Go for Managed RAP.• Need to Utilise Update Function Module: opt for Managed RAP with Unmanaged Save.• Reusable Code/Loose Coupling with Pre-existing Functionality: Choose UnmanagedRAP.• Consume Custom APIs (on-premise) in BTP: Use Custom Entities + Unmanaged RAP.• Unmanaged Queries: Combine Custom Entities + Unmanaged RAP Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
