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