Exercise 02: Creating Applications and Defining Objects
From AgileApps Support Wiki
Introduction
Types of AgileApps Applications
- Dynamic Case Management (DCM) Application
- Automates the handling of Cases, Incidents, or Investigations
- Allows for process variants for dynamic behavior
- Dynamic Case Management (DCM) Application
- Service Desk Application
- An example of a Dynamic Case Management system
- Specialized to provide additional features for customer support
- Service Desk Application
- Database (DB) Application
- A generic Web-based database application
- Like a spreadsheet but with extra capabilities
- Database (DB) Application
Dynamic Case Management (DCM) Application
The front-line of customer, partner, and employee engagement A case is a unit of work A case Object can have a different name (other than “case”) Examples:
- Service Requests
- Customer Service
- Claims Management
- Employee, Supplier, and Partner on-boarding & off-boarding
- Complex, high-value proposals
- Incident Management
- Order Exception Management
- Complaint Management
- Dispute Resolution
- Employee Health and Safety
- Investigations
- Customer Analysis
- Regulation, Audit requests, and tracking
- Compliance Tracking
- Fraud investigations
- Service Requests
Three Ways of Creating an Application
- Start with a sample application and customize it
- Create a new application:
- Import your Object and data from a spreadsheet
- Create a new application:
- Use the Wizard to start “from scratch”
Creating an Application from a Sample Application
- Select from many pre-built applications in the Marketplace
- Software AG owned source of pre-built applications
- Download for use with cloud tenants only
- Number of the available application may vary from time to time
- Select from many pre-built applications in the Marketplace
- Customize as required
Create a New Application by Importing Spreadsheet Data
- Object structure and Data only – no formulas
- Paste spreadsheet data
- OR: Load from File
Creating a New Application Using the Wizard
- Use to create a custom application from scratch
- You specify Object definitions by filling in the form
- Hint:
- Type a Field Label carefully (because it is used to create the field name)
- The label can change - the internal name never does
Components of an AgileApps Application
- An AgileApps application is composed of Objects and Object Relationships
- An AgileApps application may also include:
- Forms, Web Forms, Pages, Views, Templates, Reports, Dashboards (display data)
- Validations, Business Rules
- Macros, Processes
- An AgileApps application can integrate global and external system elements:
- Web Services, Global Picklists
- Java classes
- Web Tabs
- An AgileApps application can integrate global and external system elements:
AgileApps is Built on a Relational Database
An AgileApps Object is an Enhanced Database Table
- An AgileApps Object consists of a database table, plus:
- Forms and Layout Rules
- Field and Form scripts
- Email & Document templates
- Macro-actions, Validations, Processes
- An AgileApps Object consists of a database table, plus:
- When you define a new Object:
- internal table and default Forms are automatically generated
- Object is added as a new tab to you application by default
- When you define a new Object:
Forms to Display Object Fields
- As a developer/administrator at design-time:
- Modify (default) Forms in the graphic Form editor
- Create/clone new Forms
- Assign them to Application Roles
- Dynamically modify their behavior
- As a developer/administrator at design-time:
- As a User (Agent) at runtime:
- Use Forms to view/enter data for a record
- As a User (Agent) at runtime:
Defining Fields for an Object
- Mandatory label
- Displayed on the form
- Display Type (Field data type)
- Required or not
- Field Name (internal)
- Auto-filled
- Must begin with an alphabetic character
- Can contain alphabetical and numeric characters, and underscores
- Cannot be a reserved word (ex. BLOB, BINARY)
- Must be unique within the Object
Lookup Fields
- A Lookup is a field that points to a record of another Object
- A Lookup field defines a Many-to-One relationship
- Example: Many OrderItems point to a single Order:
- Notes:
- There could be a Products Object, as well (depending on the design)
- When you specify an Object Relationship in the application wizards, the Lookup field is created for you
- You can also create the Lookup fields yourself
- Important terms: Lookup, target, related records, Object Relationship
- Notes:
Lookup Fields and Object Relationships
Object Relationships can be configured:
- in the application wizard
- by adding child Objects to an Object
- by adding Lookup fields
Types of Object Relationships
- One-to-Many
- Many related records can point to one target record
- One-to-One
- There can be one and only one related record for each target record
- Uncommon:
- Define a one-to-many relationship
- Use program logic to restrict record creation
- Many-to-Many
- Example: Cases and Contributors
- One Case has many Contributors, one Contributor works on many Cases
- Internally, they are managed using junction Objects
- A few good things about the platform are:
- The platform makes them almost entirely invisible
- When looking at a Case, you see all related Contributors
- When looking at a Contributor, you see all related Cases
- One-to-Many
Additional Concepts Related to Lookups
- Rollup Summary Fields
- Can combine information from multiple records of a related Object
- Get a record Count, Sum, Average, Max, or Min value from those records (see ch. 4)
- Record Locators
- A Lookup field contains a pointer to a record (generally a record#)
- Record Locators tell which fields to display to identify a record when:
- a) Performing a Lookup
- b) Displaying the record
- c) Searching
- Example: When selecting a User, you see First Name + Last Name
- Record Locators tell which fields to display to identify a record when:
- A Lookup field contains a pointer to a record (generally a record#)
- Lookup-derived Fields
- Lookup-derived fields are copies of fields contained in a target record a Lookup points to
- Example: OrderItems contains a Lookup to a Products table
- The Products table might include inventory information and where to order more
- Product name could be copied into the OrderItem record for easy reference
- Lookup-derived fields are copies of fields contained in a target record a Lookup points to
- External Lookup Fields
- When the record is accessed, External Lookup fields invoke a Web Service to perform:
- a Lookup to retrieve one target-record from an external server AND/OR
- a search that returns multiple target records from an external server. User can select one record from a pop-up
- When the record is accessed, External Lookup fields invoke a Web Service to perform:
- Rollup Summary Fields
Types of Application Objects
- An Application is composed of System Objects and Custom Objects
- Some System Objects allow only limited customization:
- User: Add fields and Business Rules
- Team: Add Business Rules
- Some System Objects allow only limited customization:
- Other System Objects are very customizable:
- Cases and Tasks: Modify labels, add fields, add rules and processes
- Some System Objects are not customizable:
- UI case “banner” and sidebar-options are pre-defined (not customizable)
- Articles, Attachments, History: not customizable
- Custom Objects (those that you create) are very customizable:
- No UI banners, sidebar options are not defined
- All other options are available:
- Add fields
- Modify forms (the UI for displaying the data)
- An Application is composed of System Objects and Custom Objects
Exercise
In this exercise, you will generate three webMethods AgileApps Cloud applications in three different ways:
- In Part 1, From an Excel spreadsheet.
- In Part 2, From an existing sample Application
- In Part 3, Using the New Application Wizard.