5 Replies Latest reply on Aug 15, 2016 11:39 PM by Scott Wesley

    How to plan medium/large applications in APEX

    M.Emmanuel

      So far my experience with Apex is small applications with few tables where it is just one application and one schema.

       

      I have an application to be coded which includes several modules. Each module is usually used by one or two users which do not deal with other modules, but some users have access to several modules.

       

      To give a well-known example imagine the classic ERP modular approach where you can have sales, purchases, invoices, warehouse and accounting modules. All modules are under the same umbrella and share access to data, but at the same time they are different moduels.

       

      In such scenario, should a different application be used for each module -all under the same schema- ?

      Is that the right approach to deal with large applications in Apex?

       

      Additionally, if so, can you actually combine applications that could be switched using an upper menu?

       

      Thanks,

        • 1. Re: How to plan medium/large applications in APEX
          Scott Wesley

          If you suspect your modules are going to have different release patterns and different user sets, then no reason why you couldn't/shouldn't separate them as applications.

           

          You can dynamically source your upper menu from apex_applications, joining to whatever privilege structure you have to users only see what they have access to.

           

          The applications can share authentication using an app attribute

          Grassroots Oracle: Shared authentication across multiple APEX applications

           

          Schema management really depends. Either way, from APEX's perspective, you can define specific parsing schemas for your applications and provide them access to whatever they need, so table location doesn't really matter.

          1 person found this helpful
          • 2. Re: How to plan medium/large applications in APEX
            fac586

            M.Emmanuel wrote:

             

            So far my experience with Apex is small applications with few tables where it is just one application and one schema.

             

            I have an application to be coded which includes several modules. Each module is usually used by one or two users which do not deal with other modules, but some users have access to several modules.

             

            To give a well-known example imagine the classic ERP modular approach where you can have sales, purchases, invoices, warehouse and accounting modules. All modules are under the same umbrella and share access to data, but at the same time they are different moduels.

             

            In such scenario, should a different application be used for each module -all under the same schema- ?

            Yes. APEX itself uses that architecture.

             

            Creating large monolithic applications is definitely not recommended.

             

            Building large systems from a number of smaller, modular applications simplifies maintenance and deployment, resulting in an overall reduction in down time.

             

            The following components can be shared between applications in a workspace using the publish and subscribe model:

             

            • Authentication Schemes
            • Authorisation Schemes
            • Lists Of Values
            • Plug-ins
            • Shortcuts
            • Classic Navigation Bar Entries
            • Themes
            • Templates

             

            When building a modular system, creating a common application that doesn't do anything itself but acts as a container for common components like authentication and global authorization schemes, navigation bar, and templates that are shared through subscriptions is recommended.

             

            Applications in the same workspace can share scalar data through globally-scoped application items, but the essential ability to share structured data across applications is not yet possible.

             

            Cross application navigation is another area requiring enhancement, but effective solutions can be built using dynamic lists or a PL/SQL module called from a shortcut or dynamic PL/SQL region.

             

            Using multiple schemas to organize database objects and implement security is also recommended. However, APEX applications can only have one parsing schema so cross application/schema access must be granted using the required privileges at the database level. Note that synonyms are not supported as data sources for APEX wizard-generated forms. Views can be used instead (although in a system on this scale, the use of transactional PL/SQL APIs would be expected).

            1 person found this helpful
            • 3. Re: How to plan medium/large applications in APEX
              Sven W.

              Apex has several possibilities to allow a combination of modules. There is no single best possibility, they all have some strength and weaknesses.

               

              These are the things I consider as option on a regular basis

               

              A) Authorizations and conditions

               

              In Apex you use authorizations to differentiate between certain roles. Depending on such a role a user would have the possibility to use a module or not.

              Authorizations can be used everywhere, starting from pages, regions, buttons up to single menu entries.

              Sometimes an authorization is not complex enough or you might want to combine several authorization checks, then you can always use a condition to do the check.

               

               

              B) Built options (Using Build Options to Control Configuration )

              Build options are great to structure your application into separate modules. And during production deployment you can choose to remove a module by switching its build option off.

               

              Often build options are used to disable a certain feature or template.

               

              C) Separate Applications - single schema, single workspace

              If the modules are not so tightly integrated, but really should be able to run independently of one another, then separate applications are usefull. They can / should work on the same database schema, but often would not use the same tables (apart from a few default tables that all applications would use)

               

              Main problem here is that you need to find a way to avoid that the user needs to log on a second time, whenever he switches from one to the other app.

              Apex supports this architecture by providing shared components and subscriptions.

               

              The standard object to share data between your applications would be a database table. So in general you do not share data using session scope, but you would persist it on database level.

               

              Having separate applications also helps to allow small changes to be changed and rolled out fast, without doing a full integration test over all modules.

               

              D) Separate Workspaces

               

              This is rarely useful. Sometime it makes sense if you have a different group of developers working on the different applications and if you do not want them to share the same workspace.

               

              For completly different applications it might be the best option.

              1 person found this helpful
              • 4. Re: How to plan medium/large applications in APEX
                M.Emmanuel

                Could you please give me some guidance on where to start looking for this:

                You can dynamically source your upper menu from apex_applications, joining to whatever privilege structure you have to users only see what they have access to.

                 

                After reading your answers it seems clear to me that I need multiple applications under the same schema.

                Thanks

                • 5. Re: How to plan medium/large applications in APEX
                  Scott Wesley

                  I like that particular model, and limitations are eased after every release.

                   

                  This post is directly related, the data I posted is pretty much the output from a query to apex_applications.

                  Re: Navigation Bar and List Region output do not match

                  Here is an applied example, but just using pages within an app

                  Grassroots Oracle: CSS pull down menu using APEX List

                   

                  Scott.