Call post-processing

RISE supports post-processing a method call in  a composed method. To turn on a post-processor, simply right-click the method call and select the "Post process" menu option and then the post-processor you need. A post-processor operates on - as in changes - the return set of the method call. 

There are two types of post-processing available for list method calls: force scalar and has results. These are described separate below but we'll illustrate them using common example.

The example is the core of a project administrative system which, left-to-right, implements a project having any number of persons as members or, right-to-left, a person being the member of any number of projects. Obviously, this corresponds to a many-to-many relationship between Project and Person. The relationship itself is modeled as an entity, Member, simply because it carries further information, for instance, stating the role of the person within the project.

Typically, when a composed method returns data, from a call to list method, the composed method itself will return a list. Furthermore, the composed method will loop over any subsequent call based. This behavior might be unwanted, if you know that the called method returns exactly one row. Force scalar addresses this issue by telling the composed method that the call will return exactly one row. This means that a forced scalar list method call behaves identical to a get method call.

Note that since "force scalar" requires the called list method to return a list containing a single item, it is applicable only when calling list methods that are based on a unique attribute, index or relation. When using it on list methods that might return multiple rows or no rows at all, you need to safeguard the call using conditional execution. 

In our example, since we require each project to have a single project manager, it's convenient to be able to retrieve the project manager as an object/entity, rather than as a list of length one, even though there's no "project manager entity" available in our model. This is accomplished using a composed method, GetProjectManager, in which the "force scalar" post-processor is applied on the call to ListMemberByProjectManager (a list method returning members with the IsManager flag set). When the "force scalar" post-processor is applied the call changes color from orange to yellowish and the composition flow symbol is changed from a loop  to an orange arrow . The arrow indicates that the call return set has been linearized by a post-processor. Finally, GetProjectManager uses the the person ID, returned by ListMemberByProjectManager, to load further information about person being project manager using GetPerson. 

It should be noted that, if ListMemberByProjectManager returns zero (or more than one) row the post-processor will raise an exception terminating GetProjectManager. If this behavior isn't the intended one, you should protect the forced scalar call, for instance, using a "has results" post-processor and an execution condition, see "Has results" below. This would, typically, be the case if you want to load the project manager info as part of loading the project itself, simply since a newly created project has no members and, thus, no manager.

The "has results" post-processor is used to transform a list method call into in to a boolean flag. The flag is true if the call returns one or more rows and false if now rows where returned. Typically, "has results" is used to determine the existence of an optionally related instance, when a foreign key isn't available. Use the return value from the "has results" call, for instance, as an input to a conditional execution criteria to prevent erroneous creation or deletion of related data.

Proceeding our example, the system needs a method to add a project member. Of course, all project members are unique, thus, a person may only be added to a project once. During the information modeling this corresponds to placing a unique index on the member entity, stating that the pair of the related project and person should be unique. If any application tries to assign a duplicate, the index constraint will trigger an error terminating the assignment. In many scenarios this is the best solution, however, if the member assignment is part of a larger process (i.e. called from another composed method) this behavior might be unwanted. In this example we need a method, AddProjectMember, that assigns the person, if not already assigned, and does nothing otherwise.

The AddProjectMember method below calls the list method, ListMemberByProjectPerson. The call is known to either return an empty set or a single row. The "has results" post-processor is applied to the call to find out which and a conditional execution criteria is applied to the subsequent call, requiring the return set of ListMemberByProjectPerson to be empty in order to proceed. Note, that the "has results" post-processor changes the color of the call from orange to grayish and the composition flow symbol is changed to indicate that it's now linear.