Appian Community and Appian Academy are being upgraded. From July 24–August 3, the Appian Community will be in read-only mode. During this time, the site will be read-only and user registration will be disabled. We apologize for any inconvenience this may cause, but a more secure, stable, and performant Community experience is coming soon!

The new Appian Community launches August 3, followed by Appian Academy on August 7. During the migration, Appian Community Edition, Appian Academy, Documentation, Certifications, Instructor-led Customer Training, Partner Sales Training & Accreditation, and Forum (for Appian Partners and Customers only) will remain available.

Use of libraries in Appian

Perhaps a silly question but I'm wondering what others are doing as far a creating libraries in Appian.  Typically in other languages one would separate commonly used code into a library so that the code exists in only one location and that it can be used by other applications. 

In Appian are developers typically creating multiple libraries based on functionality or simply creating a single library to house the commonly used code?

Thanks,
Terry

  Discussion posts and replies are publicly visible

Parents
  • This is usually accomplished by grouping rules in an unpublished application.

    Please see the "Maintaining Shared Objects" section of the "Scaling Application Development" guide for more details: https://docs.appian.com/suite/help/17.3/Scaling_Application_Development.html

    In general, the use of shared objects is not recommended unless the objects do not change often. For example, a constant holding a list of state abbreviations or a rule converting a username into display name. These objects can be shared among the different applications in the environment and between releases. They need to be specially maintained because changes to these objects affect multiple applications. Keeping these objects in a separate application and hierarchy as well as using a good naming convention helps distinguish them from application-specific objects and prevents far-reaching changes from accidentally occurring.

Reply
  • This is usually accomplished by grouping rules in an unpublished application.

    Please see the "Maintaining Shared Objects" section of the "Scaling Application Development" guide for more details: https://docs.appian.com/suite/help/17.3/Scaling_Application_Development.html

    In general, the use of shared objects is not recommended unless the objects do not change often. For example, a constant holding a list of state abbreviations or a rule converting a username into display name. These objects can be shared among the different applications in the environment and between releases. They need to be specially maintained because changes to these objects affect multiple applications. Keeping these objects in a separate application and hierarchy as well as using a good naming convention helps distinguish them from application-specific objects and prevents far-reaching changes from accidentally occurring.

Children
No Data