Architectural Considerations

Embedded Solutions

All embedded solutions should have zero client footprint and are required to satisfy the below mentioned database, architecture and coding requirements:


  • Changes to system tables are not allowed. Any modification to these tables could adversely affect the solution and such changes are lost during database upgrade operation. A complete list of system tables is found in the application help (MYOB Advanced Framework > Design Guidelines > Database Design Guidelines).

  • Any new database table must meet the following:

    • Multi-tenancy support requirements
    • Table and field naming conventions
    • Use only supported data types
    • Primary Key requirements
    • Foreign Keys and Nullable fields requirements (where applicable)
    • Audit Fields requirements (where applicable)
    • Concurrency requirements
    • Support for attaching additional objects to data records (where applicable)
    • Preserving deleted records requirements (where applicable)
    • CompanyMask and GroupMask field requirements (where applicable)

    Note: These are described in detail in the application help (MYOB Advanced Framework > Design Guidelines > Database Design Guidelines).

  • Any changes to MYOB Advanced application tables or fields must not break or affect existing functionality of the MYOB Advanced application. Solution must ensure that upgrade process does not overwrite these changes and/or inflicts any data loss.

  • New tables should conform to the recommended naming convention (Refer to naming convention section for details).

  • The solution must not include database objects which are capable of running some kind of code such as stored procedures, triggers, functions, views, etc.

  • The solution must not make use of MYOB Advanced system tables or columns directly using ADO or some other mechanism that bypass the framework. All data MUST be accessed through the MYOB Advanced DACs and BQL.

Architecture and Coding

  • All solution tables must be mapped to DACs (Data Access Classes) that define the data object model of the solution. All fields must be mapped in DACs. It is preferred that no orphaned fields in tables exist.

  • All the business logic and data access must be performed using BLCs (Business Logic Controllers)

  • Custom screens, reports and BLCs should follow recommended naming conventions (See naming conventions section for more details).

  • Every solution must provide Safe Computing Environment by meeting the following requirements:

    • Only managed assemblies are permitted. No unmanaged libraries and/or unsafe code blocks are allowed.
    • No modification is permitted to the Web.Config.
    • Existing functionality of the framework should be replicated without proper justification and discussion/approval with MYOB.
    • Avoid adding external JavaScript libraries, html pages and/or adding html/JavaScript code to the application. If a Developer Partner chooses to add such code, they must be added only to their solutions pages.
    • Direct access to the session data storage is not permitted.
    • Use of .NET reflection is not permitted.
    • It is recommended that tricky logic is not employed in order to circumvent Framework functionality (like playing with parameters before persist or blocking validation event handlers, etc.)
    • Access of low level services is not permitted and the solution must operate within platform boundary.
    • Any existing application files and pages must not be modified (ASPX pages, master pages, CSS, etc.). Where changes to existing screens are required the standard customisation processes and practices should be adhered to.
  • The solution must not use 3rd party libraries that duplicate functionality of the Advanced Framework.

  • The solution must not use any 3rd party UI libraries.

  • The solution must not use any static variables or data structures.

  • The solution must leverage use of MYOB Advanced functionality by using built in DACs and BLCs where applicable. Solution must always reuse or extend and never re-invent.

  • If the solution is using external services, it must provide means to configure such external services. Any sensitive connection or configuration details must be encrypted and stored.

  • Framework Long running process constructs must be used for any process that take longer than 5 seconds to complete. Any external systems communications must implement “Long Running Process” constructs.

    Code example:

    PXLongOperation.StartOperation(this, delegate()
    SalesOrderEntry graph = PXGraph.CreateInstance();

  • Solution code must compile without any errors and Microsoft C# compiler warnings (level 4) e.g. unreachable code, etc. A complete list is found here:

  • All required fields, warnings, validations, grid line status indicators and error messages should be displayed or indicated using standardized framework constructs.

  • Developer Partner solution must support and work under instance configuration that uses out-of-process session management. This is to allow support for load balancing and fault tolerance configurations.

Deployment and Packaging

  • The Solution must have zero client footprint. It should not depend on any other software other than internet browser.
  • Deployment packages must be able to apply repeatedly without any errors on the same application instance.
  • Avoid using generic names for the sitemap item (screens, reports and GIs) that are outside of MYOB Advanced solution module menu structure. Naming conventions should be followed to avoid potential repetition and confusion while referring to them.

Connected solutions (Web services API)

  • Connected solutions that interact with MYOB Advanced must follow guidelines found in the Help under MYOB Advanced Framework > Web Services API Developer Guide.

  • It is recommended that solutions should consume Web API services of MYOB Advanced using a single web service end-point that packages all the needed functionality. Package them using Web Services screen (SM.20.70.40).

  • Solutions must employ client side schema persistence or versioned API interface to maintain schema compatibility with different versions and instances of MYOB Advanced application. This does not apply to versioned APIs.

    The following example of client side schema persistence shows saving the WSDL schema form the server in a file and deploying this file with solution to set the schema on server prior the execution:

    GL301000.Screen screenGL301000 = new GL301000.Screen();
           screenGL301000.CookieContainer = new System.Net.CookieContainer();
           screenGL301000.Login("admin", "123");
           GL301000.Content schemaGL301000;
           System.Xml.Serialization.XmlSerializer serializer = new System.Xml.Serialization.XmlSerializer(typeof(GL301000.Content));
                 using (System.IO.FileStream file = System.IO.File.Open(typeof(GL301000.Content).FullName + ".xml", System.IO.FileMode.Open))
                       schemaGL301000 = (GL301000.Content)serializer.Deserialize(file);
           catch (System.IO.FileNotFoundException)
                 using (System.IO.FileStream file = System.IO.File.Open(typeof(GL301000.Content).FullName + ".xml", System.IO.FileMode.Create))
                       schemaGL301000 = screenGL301000.GetSchema();
                       serializer.Serialize(file, schemaGL301000);
  • The solution must provide configurable means to connect to target MYOB Advanced application instance. Connection information must be securely stored with industry standard strong encryption algorithms.