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.