From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS

<keywords content="keywords"> getEntities, getentities, getEntitiesAsString, getentitiesasstring, get Entities, get entities, SOA Layer, soa layer, EntityManagerSOA, entitymanagersoa, Entity Manager SOA, entity manager soa </keywords>

Contents 1 getEntities 1.1 Description 1.2 Input Data 1.2.1 EntityData Node 1.2.2 Example 1.2.3 Valid Operators 1.2.4 Disabled Records 1.3 Output Data 1.3.1 Example 1.4 Notes

getEntities

This is a method included in the EntityManagerSOA web service which is useful to get information saved in an entity (or entities) of a Bizagi database. This document also applies to the method getEntitiesAsString.

Description

It receives an XMLDocument which specifies the entity in which the search will be performed and a filter to get a particular set of records from the table. The response is also returned in XMLDocument format. There is also a similar method, getEntitiesAsString, which receives and returns an XML in string format.

Input Data

This is the schema of the expected XML (copy it form here):

EntityData Node

EntityName: Is the name (not display name) of the desire entity. If this element is included the next one must not be.

EntityID: Is used instead of the previous method, do not include both. It is the id or key (in the database for the table ENTITY) of the entity that is to be consulted. It is easier to use this element when used in conjunction with other SOA methods, for example the ones from the web service RenderSOA, which are used to replicate Bizagi forms in a user interface of an external system, that return the ids of entities related to the metadata of the forms.

Filters: Set the filter for the consulted entity. The filter format is like a WHERE statement of a basic SQL query.

Example

This XML is used to retrieve all records from the Applicant entity with BuroScore less than 100.

Notice that the filter in this case is enclosed in a CDATA segment with the purpose of being available to use comparison operators, such as less than (<), greater than (>) and different from (<>), without problems, since these are special characters in XML.

The filter is optional; if it is not specified then all records in the entity are retrieved.

Some filter examples are:

<Filters> 
	<![CDATA[ (DocumentType = 1 OR City = 2) AND Approved = true ]]> 
</Filters> 

<Filters> 
	<![CDATA[ Option  = 'Automatic' ]]> 
</Filters> 

<Filters> 
	<![CDATA[ date1 >= '06/05/2008' ]]> 
</Filters> 

When comparing dates in filters, it is necessary to use the database's format.

Valid Operators

Operators that may be used in a filter are:

Disabled Records

Normally a query using the methods getEntities or getEntitiesAsString would not return disabled records from parameter entities. Records in parameter entities cannot be deleted (and it is recommended not to do so) but they may be disabled, so even if they are still in the database, these records will not be visible through the web application. If this information is required in the response, it can be obtained by adding the element FilterDisabled to the request XML and setting its value to false. This is an example of such an XML, using the Products entity and getting all records with ProductType equal to 3:

Output Data

The response XML will show the records that match the search. If the result includes attributes without a value (null or empty), these would not be displayed. In addition to the attributes belonging to the entity, the result will also include one level of depth, that is to say, the content of related entities will also be included; but if these in turn have related entities, the data in the latter will not be included. To be able to make queries with greater depth, it is necessary to use the method getEntitiesUsingSchema.

Example

For the sample input XML, this will be the response:

When the entity has a one-to-many relationship of a Collection type, the XML attribute key will show the id (key) of the record in the database. For one-to-many relationships that are not Collections, Bizagi will include in the response, in addition to the XML attribute key, an XML attribute called entityName with the name of the related entity.

Notes

• When using this method, keep in mind that the data is physically stored in Bizagi entities once an activity has been fulfilled. This means that the information saved in an activity (using the Save button) or subprocess, may not be stored in the entities.

Go to SOA Layer <comments />