Appian Sites

Sites is one of the Basic User interface. Sites allow the Designers to configure the specific tabs of tempo like Records, Reports , Actions and interfaces. 

In this ways the users who need to access only one tab can be provided security for that tab for  corresponding Group ,so that can work on it and complete their job. 

Unlike Tempo, when we want to display only set of tabs (Records, Reports, Actions and interfaces) in Appian We can go for sites.

We can set the visibility for the each tab in Sites to set of User groups. Each tab we use to call as a page and in each page we can display Record Type or Report or Action. 

Maximum 10 pages are allowed in Sites. (From Version 23.2)

We can configure Record, Reports , Actions and interfaces. Records means a Record list for particular Record type. Suppose the organization has many record types displayed in Records tab and we can configure particular record type to display. E.g. Patients, Doctors etc



Custom Data type (CDT) :-

CDT's are kind of representation of table structure.

Application Designers can create or import their own custom data types (CDTs). CDTs organize data into a structure that represents a logical grouping of related data, such as Doctor and Patient.

Careful attention must be paid to data types when passing the values from one variable to another (also called mapping data).

These variables can be mapped into process variables, enabling Process Modelers to access the variables in other nodes within the process model and pass the data to other processes and sub-processes.

Data types also apply to rule inputs and constants, but data from a node input or a process variable cannot be mapped to a rule input or a constant.


#) We can create CDT in 4 types/ways. 

1.Create from scratch 

2.Duplicate existing CDT

3.create from data base table or view  (Best way)

4.Import XSD (XML Schema Definition)

Example: Employee structure is a CDT, and the best is XML Schema Definition (XSD), using this we can create /update CDT in Appian.


#) Difference between nested CDT & flat CDT  ? explain with example.

Creating CDT with in a CDT is called Nested CDT.

Flat CDT will contain Primitive data type.


#) Few annotations we can use in XSD :

@ID to Primary key    

@Generated Value  to Auto Generation     

@Table to define table name 

@Column to define column 


#) Relationships:-

Flat Relationship

One-to-One Relationship

Many-to-One Relationship

One-to-Many Relationship

Many-to-Many Relationship


#) primitive system data types :-

A system data type is a required format for data stored in Appian and includes primitive types and complex types. Each system data type can be used to store either a single value or a list of values.

The following primitive system data types are available

  • Boolean
  • Date
  • Date and Time
  • Encrypted Text
  • Number (Decimal)
  • Number (Integer)
  • Text
  • Time


#) Complex System Data Types :-

The following complex system types are made available in the system to support smart services.

These types cannot be edited or deleted. Their XML structure is not guaranteed to remain the same from release to release.

  • ApplicationTestResult
  • DataSubset
  • EntityData
  • EntityDataIdentifiers
  • HealthCheckOutput
  • IntegrationError
  • LabelValue
  • LabelValueTable
  • ListViewItem
  • Facet
  • FacetOption
  • ObjectTestResult
  • PagingInfo
  • ProcessInfo
  • Query
  • Save
  • SortInfo
  • TestCaseResult
  • TestRunResult
  • Writer


#) Appian Object Data Types :-

An Appian Object data type is a required format for objects specific to the Appian system. Similar to primitive and complex system types, each can be used to store either a single value or a list of values.

Appian Object data types are only recognizable within the Appian system.


  • Application
  • Connected System
  • Data Store Entity
  • Document
  • Document Management Community
  • Document or Folder
  • Email Address
  • Email Recipient
  • Folder
  • Group
  • Knowledge Center
  • Process
  • Process Model
  • Record Action
  • Record Data
  • Record Field
  • Record Identifier
  • Record Relationship
  • Record Type
  • Report
  • SafeURI
  • Task
  • Task Report
  • User
  • User or Group
  • User Filter


#) Record Data Types :-

This data type holds the data definition for all of the fields in a record type (or a subset of fields defined by your record type configuration), as well as the data values for the record.

When you make changes to the record type object, the record data type is also updated and stays current with any configuration changes you make. 

For example, if you change the name of a record field on a record type, the change is also captured on the record data type.

The record data type allows you to easily pass record data to your interfaces, records-powered components, and expression rules.


For More Info :- Click here (Appian Site)

Note : Source of the information posted is from www.appian.com , Wikipedia and from internet.

Appian Annotations - 2

JPA Annotations :-

JPA annotations are used in mapping java objects to the database tables, columns etc. Today we will look into Appian supported JPA annotations.

When used with Data Stores, a custom data type (CDT) can be used to map data to a relational database. Your custom data types can use JPA annotations in the XSD (XML Schema Definition) to map types and their fields to tables and columns within a database.

Many of the supported JPA annotations are automatically added for you when creating a custom data type (CDT) from a database table or when defining CDT relationships in the data type designer. Should you need to add additional JPA (Java Persistence API) annotations to your XSD (XML Schema Definition), this section contains the list of all Appian supported annotations.

The following annotations are supported: 


16) @JoinTable

The @JoinTable annotation is used to specify the link table between two other database tables.


17) @Lob

The @Lob annotation is used to specify that the currently annotated entity attribute represents a large object type.


18) @MappedSuperclass

The @MappedSuperclass annotation is used to specify that the currently annotated type attributes are inherited by any subclass entity.


19) @OrderBy

The @OrderBy annotation is used to specify the entity attributes used for sorting when fetching the currently annotated collection.


20) @PrimaryKeyJoinColumn

The @PrimaryKeyJoinColumn annotation is used to specify that the primary key column of the currently annotated entity is also a foreign key to some other entity (e.g. a base class table in a JOINED inheritance strategy, the primary table in a secondary table mapping, or the parent table in a @OneToOne relationship).


21) @PrimaryKeyJoinColumns

The @PrimaryKeyJoinColumns annotation is used to group multiple @PrimaryKeyJoinColumn annotations.


22) @SecondaryTable

The @SecondaryTable annotation is used to specify a secondary table for the currently annotated entity.


23) @SecondaryTables

The @SecondaryTables annotation is used to group multiple @SecondaryTable annotations.


24) @SequenceGenerator

The @SequenceGenerator annotation is used to specify the database sequence used by the identifier generator of the currently annotated entity.


25) @Table

The @Table annotation is used to specify the primary table of the currently annotated entity.


26) @TableGenerator

The @TableGenerator annotation is used to specify the database table used by the identity generator of the currently annotated entity.


27) @Temporal

The @Temporal annotation is used to specify the TemporalType of the currently annotated java.util.Date or java.util.Calendar entity attribute.


28) @Transient

The @Transient annotation is used to specify that a given entity attribute should not be persisted.


29) @UniqueConstraint

The @UniqueConstraint annotation is used to specify a unique constraint to be included by the automated schema generator for the primary or secondary table associated with the currently annotated entity.


30) @Version

The @Version annotation is used to specify the version attribute used for optimistic locking.


31) @ManyToMany

The @ManyToMany annotation is used to specify a many-to-many database relationship.


32) @ManyToOne

The @ManyToOne annotation is used to specify a many-to-one database relationship. (with additional value of NONE for cascade attribute; default value of cascade is MERGE, PERSIST, REFRESH)


33) @OneToMany

The @OneToMany annotation is used to specify a one-to-many database relationship.(default value of cascade is ALL, which includes deleting orphans)


34) @OneToOne

The @OneToOne annotation is used to specify a one-to-one database relationship.


Appian Annotations - 1 :-   Click Here

Source : shorturl.at/fjlmY

Source : https://docs.appian.com/suite/help/22.2/Supported_XSD_Elements_and_JPA_Annotations.html



Appian Annotations - 1

 

Q) What do you understand by Artifacts ?

Ans) Artifacts allow process designers to extend the basic BPMN notation to include additional information about the process in the process diagram. There are three types of artifacts: dataobject, group, and annotation.


Q)What do you understand by Annotations ?

Ans) Annotations can be used to add textual comments within a process diagram.


Q) What is JPA in Appian ?

Ans) Java Persistence API (JPA) is the Java standard for mapping Java objects to relational databases. Since Appian BPM built on the Java platform we can use JPA annotations.


Q) What is Appian annotation ?

Ans) Your custom data types can use JPA annotations in the XSD to map types and their fields to tables and columns within a database. Many of the supported JPA annotations are automatically added for you when creating a CDT from a database table or when defining CDT relationships in the data type designer.


JPA Annotations :-

JPA annotations are used in mapping java objects to the database tables, columns etc. Today we will look into Appian supported JPA annotations.

When used with Data Stores, a custom data type (CDT) can be used to map data to a relational database. Your custom data types can use JPA annotations in the XSD (XML Schema Definition) to map types and their fields to tables and columns within a database.

Many of the supported JPA annotations are automatically added for you when creating a custom data type (CDT) from a database table or when defining CDT relationships in the data type designer. Should you need to add additional JPA (Java Persistence API) annotations to your XSD (XML Schema Definition), this section contains the list of all Appian supported annotations.

The following annotations are supported:


1) @AssociationOverride

The @AssociationOverride annotation is used to override an association mapping (e.g.  @ManyToOne, @OneToOne, @OneToMany, @ManyToMany) inherited from a mapped superclass or an embeddable.


2) @AssociationOverrides

The @AssociationOverrides is used to group several @AssociationOverride annotations.


3) @AttributeOverride

The @AttributeOverride annotation is used to override an attribute mapping inherited from a mapped superclass or an embeddable.


4) @AttributeOverrides

The @AttributeOverrides is used to group several @AttributeOverride annotations.


5) @Basic

The @Basic annotation is used to map a basic attribute type to a database column.


6) @Column

The @Column annotation is used to specify the mapping between a basic entity attribute and the database table column.


7) @DiscriminatorColumn

The @DiscriminatorColumn annotation is used to specify the discriminator column name and the discriminator type for the SINGLE_TABLE and JOINED Inheritance strategies. (a DiscriminatorColumn can have a Column attribute to define an index, or another attribute such as length)


8) @DiscriminatorValue

The @DiscriminatorValue annotation is used to specify what value of the discriminator column is used for mapping the currently annotated entity.


9) @Enumerated

The @Enumerated annotation is used to specify that an entity attribute represents an enumerated type.


10) @GeneratedValue

The @GeneratedValue annotation specifies that the entity identifier value is automatically generated using an identity column, a database sequence, or a table generator. Hibernate supports the @GeneratedValue mapping even for UUIDidentifiers.


11) @Id

The @Id annotation specifies the entity identifier. An entity must always have an identifier attribute, which is used when loading the entity in a given Persistence Context.


12) @IdClass

The @IdClass annotation is used if the current entity defined a composite identifier. A separate class encapsulates all the identifier attributes, which are mirrored by the current entity mapping.


13) @Inheritance

The @Inheritance annotation is used to specify the inheritance strategy of a given entity class hierarchy.


14) @JoinColumn

The @JoinColumn annotation is used to specify the FOREIGN KEY column used when joining an entity association or an embeddable collection.


15) @JoinColumns

The @JoinColumns annotation is used to group multiple @JoinColumn annotations, which are used when mapping entity association or an embeddable collection using a composite identifier.


Appian Annotations - 2 :-   Click Here

Source : shorturl.at/fjlmY

Source  : https://docs.appian.com/suite/help/22.2/Supported_XSD_Elements_and_JPA_Annotations.html



Business process management (BPM)

 



Business process management (BPM) is a discipline involving any combination of modeling, automation, execution, control, measurement and optimization of business activity flows, in support of enterprise goals, spanning systems, employees, customers and partners within and beyond the enterprise boundaries. 



Gartner defines business process management as:

"the discipline of managing processes (rather than tasks) as the means for improving business performance outcomes and operational agility. Processes span organizational boundaries, linking together people, information flows, systems, and other assets to create and deliver value to customers and constituents."


It is common to confuse BPM with a BPM suite (BPMS). BPM is a professional discipline done by people, whereas a BPMS is a technological suite of tools designed to help the BPM professionals accomplish their goals. BPM should also not be confused with an application or solution developed to support a particular process. Suites and solutions represent ways of automating business processes, but automation is only one aspect of BPM.



Note : Source of the information posted is from www.appian.com , Wikipedia and from internet.

Best practices for Application Import/Export

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

17.Best practices for Application Import/Export :-


1.Change Management :-

While Appian versions most individual components, it is still important to have a change management process in place.

Store application-related scripts, code, documents, etc. in folders within the main application’s folder. Housing this code in Appian folders provides versioning and should be included in the application package. For example, a Vendor Management application folder structure could consist of the following hierarchy:

Vendor Management

•VM Application

•VM CSS

•VM Icons

•VM Images

•VM Reference Docs

•VM Reports

•VM SQL

•VM Templates

•VM XSDs

VM Requests

 •VM-0001

•VM-002

•…

Note also that the security needs of these folders are different: very few people should be allowed to change the system documents in VM Application, but the entire user community requires read/write access to the project folders in VM Requests.

Document which plugins, including the version, are used by the application. This list should be referenced when standing up a new environment, upgrading an existing environment, or attempting to use a newer version of a plugin.

Applications should not be imported as named users. Process models imported or published as named users will stop functioning if the named user is deactivated. General Application Design.

When creating rules it is important to segregate rules that are consistent across environments and rules that will change based on which environment they are in, and then update the environmentally dependent rules on import to a new environment. For example: drop down constants will always be the same, but email fields in the development environment will be assigned to the developers and when the application is imported to the test or production environment those assignments will have to be changed to test or actual users. To make such rules easy to find, they should all be in an environment dependent folder, and when the application is imported all the rules in that folder will be easy to find and update so they are not overwritten with the development-environment versions.


2.The Dependency Checker :-

The dependency checker does not check for everything, so it is important to add certain items to the application as they are created. The following types of objects should always be added manually as they are created:

   •Rules, constants, and their folders that are used only on dashboard channels

   •Constants or rules utilized in the assignment expression for swim lanes.


Best practices for Database Management Standards

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

16.Best practices for Database Management Standards :-


Whenever possible, tables should be created by Appian when publishing a data store vs. writing a SQL script to create them manually. If the application is referencing an existing table then this is not possible, otherwise, this is the preferred approach (less error-prone).

Tables and views should be prefixed with the short name or acronym of the application. For example, Sales Contract Management tables are all prefixed with “SCM_”. Views should have SCM_V_ to indicate the referenced table is actually a view.

The SQL to create or replace a database view should be contained in a DDL or SQL file and stored in folder within Appian. This will allow for version control and provide a single location for all of the application’s SQL.

Add an “active” bit column should be used to denote active vs. inactive data. To prevent data relationship and integrity issues, avoid the deletion of rows. Use an active flag to denote active vs. inactive data. Queries can then filter on that column to return the desired data.


Best practices for Application Performance and Scalability Standards

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

15.Best practices for Application Performance and Scalability Standards :-


Use utility and task process models as much as possible and keep the main (long-running) process models lightweight and simple.

Since Appian uses an in-memory database, memory usage should always be considered when designing an application. The goal is to keep only the information required for reporting active in the system. Data that is required for long-term reporting can be exported to an external database then purged from Appian (assuming a third-party reporting tool is available).

Utility and task process models allow the bulk of the work to be done outside the main model. The result is less memory usage for the longest-running models since they have fewer PVs, fewer nodes, and a shorter process history.

Aggressively archive utility and task process models.

Most utility and task process models can be archived shortly after completion. If a task model is required for reporting, consider creating a task history process model that stores only the data required for the reports. The task history process model would consist of a start event connected to an end event. This simple task history model will consume less memory then the original task model.

Avoid activity chaining through long running nodes, or large number of running nodes. 

Use exact() function

Especially when comparing predefined strings. exact() is three times faster but will be case sensitive. = operator is not case sensitive but take longer. Best use case is to use constants for button labels and use exact function inside XOR gateway to determine with button is clicked.

Do not overuse if (condition, true, false) logic.

If same logic is used more than twice, start using rule instead.

For example, to display vendor name if you are coding vendor.lastname & “, “ & vendor.firstname, consider moving the logic to rule and pass either individual arguments or CDT itself (AnyType).

Before querying a database for data, make sure the same data is not available in process variables of current process or parent process.


Best practices for Security

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

14.Best practices for Security :-


1.The desired security settings will have to be remade in the new environment. A common error to this effect would be a basic user being unable to use a query rule due to a privilege exception, despite the query rule having the proper privileges. If this error is received, check the security of the data store in the environment where the error occurs.

2.All objects must have proper security defined. CDTs, Data Stores, Process Models, Process Model Folders, Process Instance Security, Record Types, Reports, Community, KC, Document Folders, Feeds, Applications.

3.Always use a normal end user for unit testing. Do not use system admin (everything works fine for developer and nothing works for tester).


Best practices for Creating Web APIs

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

13.Best practices for Creating Web APIs :-


1.Ensure that proper security is configured

2.Expression may not be longer than 4,000 characters.

3.Custom Status Code can be defined in the response to handle the custom validations message based on the returned status code

4.All Web APIs must return an HTTP Response.

5.Use WEB API when REST/HTTP protocol is used

6.Ensure that end point is included so that can be called by other systems

7.Validate the request body before processing the request. If the request is JSON, validate the json structure and data using JSON schema validator

8.Ensure to maintain the proper API specification(Eg:API spec can be defined in Swagger)

9.It is recommended to create a service account for each system that will be interacting with Web APIs.

10.It is no longer recommended to publish process models as a web service. Instead use a Web API with a! start Process to start a process from an external system.


Best practices for Creating Integration

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

12.Best practices for Creating Integration :-


Connected Systems :-

1.Name must be unique

2.Ensure that proper security is configured

3.Ensure the authentication is configured

4.Use API Key for authentication as API key has good performance than basic authentication


Integration :-

1.Maintain passwords in import customization properties files

2.Check whether the connected system is used to share credentials across multiple integrations

3.Handle integration errors based on the error codes returned by the Integration object

4.Ensure that custom logic is built to capture the integration errors and alert the admins about the failures like assigning a task to admin or send mail to admin

5.Combined size of the files in the request body of a single integration cannot exceed 75MB.

6.Request bodies over 5 MB cannot be processed and will cause the integration to return an error. However, the file size of documents being sent do not count towards this limit.

7.Ensure that proper security has configured

8.Use Integration object when REST/HTTP protocol is used.


Best practices for Creating Process Reports

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

11.Best practices for Creating Process Reports :-


1.Format all the SAIL code expressions.

1.Make sure all the process models including the sub process has the same name for the process variables, which used to display in the report.

2.Use only the process variables from the sub process, which used as pass by reference.

3.Always use numeric comparison rather than text for the logic implementation.

4.Try to use functions such as exact instead of equal to operator.

5.Provide the meaningful display name for all the columns in the report.

6.To display “My tasks” report, use Task report by context by user instead of Process report which again needs to filter based on the logged in user



Best practices for Creating Sail

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

10.Best practices for Creating Sail :-


1.Format all the SAIL code expressions.

2.Comments to be present in every SAIL rule indicating the purpose/function of the major components.

3.Identify and Design reusable SAIL interfaces

4.Identify and move common interfaces or sections into reusable rules.

5.Use local variables instead of rule input (ri) for saving manipulations, unless you need to pass the value to parent rules.

6.Use smart service functions on button actions wherever possible.

7.Create reusable custom components.

8.Always set default test values for Interface rules, so that the Live View is visible.

9.Use Decisions instead of nested/multiple if conditional validations.

10.DO NOT call SAIL expression directly in expression editors, instead create separate interface rules and map the same.

11.SAIL interfaces should not contain more than 20 inputs

12.DO NOT use dynamic behavior for offline forms.

13.Use form validation messages for problems that are not specific to a single component.

14.DO NOT have database calls in ‘with()’ function or inside a looping function like a!forEach.

15.Either a billboard layout may have a bar overlay or a column overlay.

16.Use ‘showWhen’ parameters instead of complex if, else condition to hide or show components.

17.Use Decision components instead of complex expression rules.

18.Use pagination in grids to avoid all the data displayed in a single page.

19.Use validation groups for multiple rule validations.

20.Avoid mixing box layouts and section headings.

21.Always left align grid columns for better readability.


Best practices for Creating Sites

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

9.Best practices for Creating Sites :-


1.Site name should be UNIQUE and meaningful.

2.Configure proper security for sites. Users must have at least viewer configured for the site.

3.Web address identifier must be unique across sites in your system.

4.Select the appropriate page width for the content.

5.Site logo must be less than 100 KB.

6.Site logo should be a JPG, PNG, BMP, JPEG or GIF file with a transparent background.

7.Use favicon and branding to have Intuitive, and Beautiful Site pages.

8.Site Favicon should be an ICO file with sizes 16x16 and 32x32 that is less than 100KB.

9.Every site should contain relevant tabs/menu defined for specific user group.

10.Pages/Interfaces to be configured with right security and visibility

11.Configuring a site page for web users, consider updating the page width to match the content. For example, actions may have only a few fields and benefit from a narrow page width to avoid having the form look stretched. Another example is a dense report that can benefit from a wide page width or, if users have extra wide monitors, a full-page width.

12.Use a site logo with a transparent background and sufficient contrast against the navigation bar color.

13.Avoid the use of news entry links in sites.

14.Show only the required information in the Site Forms.



Best practices for Creating Reports

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

8.Best practices for Creating Reports :-


1.Keep Report Names Simple and Concise.

2.Configure proper security for tempo reports.

3.Limit the Number of Series Values and Categories.

4.Limit the Number of Chart SAIL Components on the UI.

5.Limit Queries to External Databases (not more than 3) as it affects the performance of the reports.

6.Use Query entities for querying external DB.

7.Use Appropriate Column Layouts for Report Content.

8.Keep Chart Labels Short.

9.Minimize the Number of Chart Series and Categories.

10.Limit the Number of Grid Columns and Keep Text Short.

11.Accessible Reports Must Provide a Plain-Text Representation of Data.

12.Configure relevant constants, interfaces and expression rules for tempo report design.


Best practices for Creating Records

 


 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

7.Best practices for Creating Records :-


1.Prefix Singular Record Type Name with application name. (Example: <APPPREFIX> Record Management)

2.Plural Record Type Name and description should be UNIQUE and named properly for the end users to read.

3.All Record Types should have security defined for Administrators and Viewers.

4.Define all the List Views and Dashboards in rules (and not directly in the Expression fields).

5.Use additional views or tabs to display more details in an effective manner.

6.All dashboards use the function load() or a!localvariables() when displaying paging grids and dynamic behaviors.

7.Avoid Using Complex Expressions for Record Titles

8.Avoid using slow expressions.

9.Provide High-Resolution Images for Record Icons

10.Use Distinct Images for Records.

11.Configure related actions without process start forms.


Best practices for Creating Rules & Constants

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

6.Best practices for Creating Rules & Constants :-


Rules and constants share the same namespace, all names must be unique in the environment, not the application.

1.Constants :-

1.Follow the naming convention for Constant as APPPREFIX_ALL_CAPS. (Example: APP_CONSTANT_VALUE)

2.DO NOT name constant with existing Appian functions.

3.All Constants should have proper descriptions.

4.All Constants are organized into application specific folders

5.Mention environment specific constants while creating Constants

6.All Constants should inherit security from the folders.


2.Expression Rules :-

7.Follow the naming convention for Expression Rules as APPPREFIX_camelCase () along with valid description. (Example: <APP>_formApplicationId)

8.DO NOT name Expression Rules with existing Appian functions.

9.Organize the rules into application specific folders.

10.Use comments /**/ to describe the rules logic.

11.Configure Test cases for all expression rules

12.Avoid using the ‘and() ‘ function to group assertions together for easy debugging

13.Update test cases every time the expression rule changes.

14.Analyze the performance view of the Expression rules to optimize the code.

15.Use Query Entity to fetch the specific columns with necessary selection/aggregation from DB

16.Query filters in queryEntity should have null check before executing.


3.Interfaces :- 

17.Save useful default test inputs for each interface; Save at least 2 test cases for each expression rule

18.For every rule that is edited/created, use dependency checker to ensure that everywhere the rule is called, all inputs are specified

19.All rules are properly formatted and readable.

20.Leave comments in the SAIL for every major code change made


4.Decision :-

21.Specify the values for all the inputs in decision

22.DO NOT delete Decision Objects

23.Output Objects of the decisions should present in the each environment.

24.Use decisions for Complex or Business specific Logic implementation.


Best practices for Creating Process Model

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

5.Best practices for Creating Process Model :-

1.All process models should follow the naming convention using the form “Verb Noun” prefixed by application name.(Example <APPPrefix> Create User)

2.All process models should have security defined at the lowest security level as possible.

3.All process models should have dynamic display names.

4.All process models should define shortest archiving period as much as possible.

5.All process models should have alert configured to the application administrator or process designer groups.DO NOT configure alert to individual users.

6.Process models should have proper Swim lanes and Annotations.

7.Swim lanes task assignments to be used only if all the tasks are to be actioned by a single group

8.Process models should not have more than 30 process nodes.

9.Process nodes should follow the “Verb Noun” naming convention (Example: Get Task List)

10.Unattended process nodes should be assigned to execute in context of designer instead of initiator

11.Process models should not have more than 50 process variables.

12.Process Variables should follow camel case naming convention.(Example: listRecords).

13.All the process models needs to create in a specific folder related to the application.

14.Provide Folder and process model security to access the process models

15.Provide display name and the description for every node present in the PM.

16.Set the priority as normal for all nodes

17.Process nodes should be visible within the canvas of process model designer and the node connectors should not overlap.

18.Should label all gateway nodes in the process model in the form of questions.

19.Label all the outgoing flows from gateway.

20.XOR/OR gateways should have single incoming flow.

21.XOR gateways are preferred over OR gateways as much as possible.

22.Two gateways should not connect together.A script task or a dummy node can be used in between two gateways

23.Scripts task to be configured only with Data Output and not Data Inputs

24.Configure all the task display names in the UI by means of expression rules.

25.Configure Assignments in the UI node by assigning groups or a process variable containing the assignee.DO NOT configure task assignment to a user directly.

26.Avoid using Deprecated functions.

27.Use Query Entities / Write to Data store nodes instead of Query Rules and Query Database node.

28.No CDTs should be configured as "Pass by reference" in the inputs of the sub process.

29.Save Utility process models in the separate folder.

30.Exception path has to be set using expression rules and constants for User input Task.

31.Timer values should be stored in Constants and use the constants for all timer configurations in the process.

32.Use SAIL wizard instead of activity chaining with multiple user input tasks.

33.Enable “Delete the previously completed/Cancelled instances” for nodes that will be executed in loops

34.Designers should not reuse process models across applications.

35.If a PV is passed into a sub process, the sub process and the parent process should have the same PV name.If they do not have the same PV name, task reports will not be able to show the data correctly because tasks in the sub process cannot see PV names in the parent process.


Best practices for Creating KC & Documents

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

4.Best practices for Creating KC & Documents :-

KC (Knowledge Center) :-

1.Provide proper name with description.

2.DO NOT use duplicate names while creating Knowledge Center.

3.Configure appropriate Security and inherit the same for folders created inside KC.

4.Create the knowledge center with required folder structure to store the application specific documents

5.When modifying the Knowledge Center's expiration date, enter the number of days until it expires, not an actual date.


Documents :-

1.Links to documents should always be linked through constants, not to the document directly. If the document is then changed, or a new version is uploaded, then the process or channel does not need to be updated; only the single constant needs to be updated for all the links that document might have in the application.

2.Reference documents should all be kept in the same folder with a corresponding folder of constants with which to reference them.


Best practices for creating Group

 

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

3.Best practices for creating Group :-

1.Keep group names short but descriptive and use the application prefix. (Example.<APPPrefix> Administrator)

2.Keep group names unique and provide a valid description.

3.Avoid creating custom group types unless there is a strong need/requirement

4.Only create the groups necessary for task assignment or security

5.DO NOT delete groups once deployed to other environments.

6.All groups must have an administrator group defined.

7.DO NOT add users as administrators to a group.

8.Use the same prefix for all groups of a specific application.


Best practices for creating CDT & Data Store

 Best Practices for Appian developers


Appian best practices are like a check list, use these checklists at different stages of your development cycle as described to ensure application success and reduce technical risk. Each section provides guidance for when and how often you should use these.

2.Best practices for creating CDT & Data Store :-

CDT(Custom Data Type) :-

1.Follow the naming convention as AppPREFIX_camelCase (Example: <APP Prefix>_nameCDT)

2.Provide proper description for a CDT

3.CDTs should use application-specific namespace. (Example: urn:com:appian:types:<App Prefix>)

4.The CDT name should closely match the underlying database table/view name with the appropriate format.

5.All CDTs should contain no more than 50 fields.

6.Specify column names not more than 27 characters.

7.All CDTs stored in data store should expose a primary key.

8.CDTs should not have more than 1 level of nested CDTs

9.CDT should have proper column definitions (define in XSD) in accordance with the underlying database table.

10.Avoid rename, delete or change the type of existing CDT fields.

11.Include nullable as true annotation wherever applicable.

12.When adding new fields to CDT already in use, ensure that the process models and rules using this CDT can properly handle null values in the new CDT fields.

13.Create CDT with parent child relationship by specifying the primary key element in all child tables.

14.If flat CDTs have fields that store IDs of other records, the CDTs should have foreign key constraints defined in the database schema.

15.Designers should not reuse CDTs across applications.


Data Store :-

1.All data stores should follow the naming convention with Application Prefix. (Example: <APP> My DS)

2.Provide proper security to the Data store to access the DB entities. (Admin group as administrators and All Users group as Editor).

3.Have separate data store for CDTs of tables and views.

4.Entities inside the data store should follow camel case naming convention.


MOST VIEWED