Business logic objects
You can design the business logic objects such as Active links, filters, guides, and escalations. This topic explains the guidelines for designing the business logic objects.
Active links
This section provides guidelines for designing active links. For information about the purpose of active links, see Active links
Active link naming
This section provides the naming convention for active links. The standard format for the name of an active link is as follows:
System Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Active link name format
Parameter | Definition |
---|---|
System Code | System code that uses two to six uppercase letters |
Form Code | Actual form code. If the active link is shared, use SHR. The form code is optional but it must be consistently used within systems and application suites. |
Field/Button/Guide Name | Associated field name, button name, or guide name, if applicable. This value is optional. |
Description | Functional description of the workflow performed. The description should be brief but informative (approximately 15 – 40 characters). Use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase letters and no space between words. |
### | Optional sequence order if an active link is part of a series. Use three digits. Allow some gaps in the sequence order for expansion (for example, 010, 020, 030). The sequence order is not the same as the execution order number, which should not be included in the name. |
Operational Description | This parameter is optional and free-form. Establish standards within applications and across suites. Some common operations are Initialize, Validate, Message, Process, Get, Set, Modify, Delete, Submit, and CallGuide. Examples are ValidateRequestID and CheckDuplicate. |
Integration-specific active link naming
Integration active links exist between two systems, one of which is not part of the Foundation module. These active links are not required in either of the two stand-alone systems.
These active links are named to belong in an integration system identified by the INT integration system code and the system link code which consists of combining in alphabetical order both systems codes for the integration.
Naming convention for integration-specific active links
The standard format for the name of an integration-specific active link is as follows:
INT:System Link Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Active links that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. These active links might be used in several integrations and will be loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation active links
The standard format for the name of an integration-preparation active link is as follows:
INT:System Code:[Form Code]:[Field/Button/Guide
Name]Description[###]_[Operational Description]
Shared active link naming
Active links shared within and across the Foundation module and applications have a SHR: system code and a SHR: form code.
Naming convention for shared active links
The standard format for the name of a shared active link is as follows:
SHR:SHR:[Field/Button/Guide Name]Description[###]_[Operational Description]
Filters
This section provides guidelines for designing filters. For information about the purpose of filters, see Filters
Filter naming
This section provides the naming convention for filter names. The standard format for the name of a filter is as follows:
System Code:[Form Code]:[Guide Name]Description[###]_[Operational Description]
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Filter name format
Parameter | Definition |
---|---|
System Code | System code that uses two to six uppercase letters |
Form Code | Actual form code. If the filter is shared, use SHR. The form code is optional but must be consistently used within applications and suites of applications. |
Guide Name | Associated guide name, if applicable. This value is optional. |
Description | Functional description of the workflow performed. The description should be brief but informative (approximately 15 – 40 characters). Use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase letters and no space between words. |
### | Optional sequence order if the filter is part of a series. Use three digits. Allow some gaps in the sequence order for expansion (for example, 010, 020, 030). The sequence order is not the same as the execution order number, which should not be included in the name. |
Operational Description | This parameter is optional and free-form. Establish standards within applications and across suites. Some common operations are Initialize, Validate, Message, Process, Get, Set, Modify, Delete, Submit, and CallGuide. Examples are ValidateRequestID and CheckDuplicate. |
Integration-specific filter naming
Integration filters are those which exist between two systems one of which is not part of the Foundation module. These filters are not required in either of the two stand-alone systems. These filters are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining (in alphabetical order) both system codes for the integration.
Naming convention for integration-specific filters
The standard format for the name of an integration-specific filter is as follows:
INT:System Link Code:[Form Code]:[Guide Name]Description[###]_[Operational
Description]
Filters that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. Such filters might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation filters
The standard format for the name of an integration-preparation filter is as follows:
INT:System Code:[Form Code]:[Guide Name]Description[###]_[Operational Description]
Shared filter naming
Filters shared within and across the Foundation module and other applications have a SHR: system code and a SHR: form code.
Naming convention for shared filters
The standard format for the name of a shared filter is as follows:
SHR:SHR:[Guide Name]Description[###]_[Operational Description]
Execution order
The following table specifies reserved filter execution orders:
Filter execution order ranges
Execution order range | Filter function or action |
---|---|
000 – 025 | Reserved for Goto filters |
800 – 899 | Reserved for Notification filters |
900 – 990 | Reserved for Audit filters |
990 – 999 | Reserved for Goto filters |
You should stagger execution orders between the range of 026 – 799, allowing some gaps within blocks of code so that it is possible to add new workflow if needed.
Filter Help text
Help text is a requirement. Always complete the Help text field found in the Help text tab of the filter. Ensure that the Help text is informative for other developers as well as the administrator, and include details if it is part of a workflow sequence.
Guides
This section provides guidelines for designing guides. For more information about the purpose of guides, see Creating guides
Guide naming
This section provides the naming conventions for guides for both active links and filters. The standard format for the name of a guide is as follows:
System Code:[Form Code]:Description
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Guide name format
Parameter | Definition |
---|---|
System Code | System code that contains two to six uppercase letters |
Form Code | Actual form code. If the guide is shared, use SHR. The form code is optional but it must be consistent within applications and suites of applications. |
Description | Functional description of the workflow performed. The description should be brief but informative (approximately 15 – 40 characters). Use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase letters and no space between words. |
Integration-specific guide naming
Integration guides are those which exist between two systems one of which is not part of the Foundation module. Such guides are not required in either of the two stand-alone systems. These guides are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining in alphabetical order both systems codes for the integration.
Naming convention for integration-specific guides
The standard format for the name of an integration-specific guide is as follows:
INT:System Link Code:[Form Code]:Description
Guides that contain preparation workflow for the integration and are not required in the stand-alone application are also part of the INT system and use the system code of the system in which they were created. Such guides might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation guides
The standard format for the name of an integration-preparation guide is as follows:
INT:System Code:[Form Code]:Description
Shared guide naming
Guides shared within and across the Foundation module and other applications have a SHR: system code and a SHR: form code.
Naming convention for shared guides
The standard format for the name of a shared guide is as follows:
SHR:SHR:Description
Escalations
This section provides guidelines for designing escalations. For information about the purpose of escalations, see Escalations
Escalation naming
An escalation starts on all records that match the qualification criteria assigned to it. If an escalation is meant to start only once at the specified interval or time, ensure that no more than one record matches the qualification criteria. This section provides the naming conventions for escalations. The standard format for the name of an escalation is as follows:
System Code:[Form Code]:Description
Square brackets denote optional parts of the name. See the following table for definitions of the parameters in the name.
Escalation name format
Parameter | Definition |
---|---|
System Code | System code that uses two to six uppercase letters |
Form Code | Actual form code. If the escalation is shared, use SHR. The form code is optional but it must be consistently used within applications and suites of applications. |
Description | Functional description of the workflow performed. The description should be brief but informative (approximately 15 – 40 characters). Use CamelCase notation, which is a mixture of uppercase and lowercase letters with each distinct word beginning with an uppercase letter followed by lowercase letters and no space between words. |
Integration-specific escalation naming
Integration escalations are those which exist between two systems, one of which is not part of the Foundation module. These escalations are not required in either of the two stand-alone systems. These escalations are named to belong in an integration system identified by the INT integration system code and the system link code, which consists of combining in alphabetical order both systems codes for the integration.
Naming convention for integration-specific escalations
The standard format for the name of an integration-specific escalation is as follows:
INT:System Link Code:[Form Code]:Description
Escalations that perform preparation workflow for the integration and are not required in the stand-alone applications are also part of the INT system and use the system code of the system in which they were created. These escalations might be used in several integrations and are loaded for all integrations that contain a matching system in the system link code.
Naming convention for integration-preparation escalations
The standard format for the name of an integration-preparation escalation is as follows:
INT:System Code:[Form Code]:Description
Shared escalation naming
Escalations shared within and across the Foundation module and applications have a SHR: system code and a SHR: form code.
Naming convention for shared escalations
The standard format for the name of a shared escalation is as follows:
SHR:SHR:Description
For information about defining service actions for active links, filters, and escalations, see Service action .
Comments
Log in or register to comment.