Apex Designer Documentation
What's New
Getting Started
Projects
Business Objects
Processes
User Interfaces
App Behaviors
Files
Dependencies
Project Settings
Libraries
Patterns and Best Practices
App Showcase
Frequently Asked Questions

Business Object Behaviors

Add logic to your business objects.

Blank Profile Image
Written by David Knapp
Updated 2 years ago
4 min read

When you create a business object, Apex Designer will automatically generate the create, read, update and delete (CRUD) behaviors. These can be extended by adding new behaviors to perform additional actions. You add or open behaviors on the Business Object Page.

Business object behavior page

Behavior Type Section

The top left section is Behavior type. When you expand it, the first field is "Type" and it has three values:

  1. Instance Behaviors add logic that is specific to an instance. An example would be an "inactivate" method on a supplier.
  2. Class Behaviors add logic that is not specific to an instance. An example would be a "rankByCapacity" method on Supplier. 
  3. Event Handlers add logic that will be run when a specific event occurs

Instance Behaviors and Class behaviors have an "Http Verb" which defines the type of REST API that should be associated with this behavior:

  1. Get is typically used for retrieving information
  2. Post is typically used for creating information
  3. Patch is typically used for updating information
  4. Put is typically used to replace information
  5. Delete is typically used for deleting information
  6. Server Only indicates that the behavior should not be exposed as a REST API

Post, patch and put behaviors have two additional advanced use fields which are typically left at the default:

  1. Request Content Type defines how information is sent to the API
  2. Request Body Parser defines how the incoming information will be parsed

Event Handlers have an "Event" field that indicates when the behavior is called:

  • Before Create is run before an instance is created and could be used to set defaults for example.
  • After Create is run after an instance is created and could be used to trigger notifications for example.
  • Before Update is run before an instance is updated and could be used to set last modified date for example.
  • After Update is run after an instance is updated and could be used to trigger notifications
  • Before Save is run before an instance is created or updated.
  • After Save is run after an instance is create or updated.
  • Before Delete is run before an instance is deleted.
  • After Delete is run after an instance is deleted.
  • Before Access is run before a read operation is sent to the underlying connector.
  • After Start is run once after the application starts and could be used to initialize information in memory
  • After Read is run after information is retrieved from the underlying connector

Parameters Section

The Parameters section defines the inputs to the behavior. There are some standard parameters:

  • Instance (supplier of type Supplier for example) is the first parameter for Instance Behaviors and many of the Event Handlers
  • Data is the second parameter of Before Update event handlers and contains the changes that will be applied to the instance
  • Options is the last parameter to all behavior types and contains context information like who is making the request (you can learn more in Using Options in Business Object Behaviors)

You can add additional parameters if needed (effectiveDate in this example):

Parameter list

Return Type Section

Instance and Class behaviors have a return type that defines the output of the behavior. The default of "void" indicates that there is no output from this behavior.

Implementation Section

The Implementation section is the heart of the behavior and contains the business logic as a small chunk of code. It can be as simple as a single line:

supplier.lastUpdated = new Date();

You can learn more about the business logic in the implementation section in these pages:

This page does not have any child pages.

Dependencies Section

The Dependencies section has the current business object by default. You can add other business object as well as npm packages that you use.

Access Rules Section

The Access Rules section lets you define which teams can using instance and class behaviors that are exposed as REST APIs.

Where Used Section

The Where Used section shows you where this business object behavior is referenced.

Icon Buttons

code View Generated Files show the source files generated from this behavior

content_copy Copy copies this behavior to paste in this project or other projects

list Test Suite opens the test specifications for this behavior (see Business Object Behavior Test Suite for more details)

bug_report Copy Debug String copies the debug string for this behavior (see Debugging Behaviors for more details)

settings Settings opens the settings dialog

assignment_turned_in Todos opens the list of todo items for this behavior

delete Delete deletes the behavior after confirmation

Settings Dialog

Clicking the settings icon button settings opens the settings dialog:

Behavior settings dialog

  • Display Name is the name shown in other parts of the Apex Designer user interface
  • Name is the name of the behavior and also the name of the method in the code (lower camel case by convention)
  • Description contains the documentation for this behavior
  • Path defines the path of the REST API for this behavior
  • Invocation defines whether this is an Asynchronous or Synchronous (rarely used) or Callback (should not be used going forward)

 

 

Powered by Apex Designer
Terms of ServicePrivacy Policy
© 2017-2024 Apex Process Consultants