An easy way to update an entity which is not related to the data model is to use the CEntityManager method called GetEntity. This comes in handy when the SOA layer is not accessible as this is the only way you can perform this operation.
Category: Tips and Tricks
Categories
Date, DateTime data types
Convert Date or DateTime to String data type
var sDateTimeFormatted = dDateTime.ToString("MM/dd/yyyy hh:mm");var sDateFormatted = dDate.ToString("MM/dd/yyyy");Or you could use String.Format
var sDateFormatted = System.String.Format("{0:d}",DateTime.Now);Use this to convert it for XML
var dTransactionDate = DateTime.Now;
var sTransactionDate = XmlConvert.ToString(dTransactionDate, XmlDateTimeSerializationMode.Unspecified);
Dates as filters for entities
[dDateDelivered != null AND dDateDelivered >= '08/22/2019 12:00:00 AM']Bizagi’s way
<format-date(<XPath>,"format")>
Categories
Escape Character in Bizagi
Use backslash (\) for string escape. See the following examples:
var sAttribute = "test";
var xCollection= Me.getXPath("entity-list(\"mEntity\", \"sAttribute = '"+ sAttribute +"' AND bActive = 1\")");var xCollection= Me.getXPath("entity-list('mEntity','sAttribute = \"test\" ')");Web portal error in Bizagi
Error Type: BaseException
Error Message: Unable to process control: _. Control type: ContentPanel. Unable to process property: _. Error processing Rule = _; Error: Error Evaluating Rule _ -Error Could not generate assembly for [C:\home\site\wwwroot\App_Data\Temporary\ComponentLibrary\BizAgi.ComponentLibrary.CRuleContextJS.js]: Errors: Error Line,Column:596,26 Error Description: ‘get’ is a new reserved word and should not be used as an identifier
Why private processes are not good?
I present two important reasons why you should not use private processes within Bizagi:
- Reporting Challenges: One significant problem I have encountered is related to reporting. When cases are marked as private, the information displayed in reports depends on the user running the report. If the user has access to the case, the related information will be included in the report. However, if the user does not have access, the information will be excluded. This can create complications when you have a Manager role specifically designated for reporting purposes only. In such cases, the manager needs to be granted permission to view case details in the reports using commands like “CHelper.GrantCaseAccess(Me.Case.Id, iUserId).” But what happens when a new manager is added to the role? Do you have to run the same command for all the existing cases? While it is technically possible, it would be more convenient if this process was simplified.
- Access Management Challenges: The second issue with private processes is related to the constant changes in personnel who require access to the cases. As roles change or new people are assigned to a particular role, the access to cases should be dynamic. However, when using private processes, manually managing these access changes can become cumbersome. It becomes necessary to constantly update permissions and ensure that the right individuals have access to the appropriate cases. This can be time-consuming and prone to errors.
Considering these challenges, I strongly recommend avoiding the use of private processes in Bizagi. Instead, it is advisable to explore the following alternative approach that offers more efficient and dynamic ways of managing reporting and access permissions within the system.
What should I use instead?
I strongly recommend utilizing visibility rules on the summary form instead. By implementing simple expressions that evaluate whether a user’s role matches certain criteria, you can determine whether they should have access to the summary page. For example, if a user has the role of Manager, you can allow access to the summary page. On the other hand, if the user has a different role that shouldn’t have access to the case, you can restrict their access.
Visibility rules based on user roles are straightforward to manage and modify in the future if needed. If there are changes to the roles or access requirements, you can easily update the expressions without extensive manual adjustments. This flexibility ensures that the access permissions remain aligned with the evolving needs of your organization.
By utilizing visibility rules, you can simplify the process of controlling access to the summary page in Bizagi. It provides a more efficient and dynamic approach compared to using private processes.
Categories
Collections in Bizagi
Case Scenario: The Peer Review process
Process Description: The Peer Review process is a collaborative approach that involves two key participants: the Reviewer and the Developer. In this process, the Developer examines and evaluates the code created by the Reviewer. The purpose of this examination is to ensure the code meets certain standards and to identify any potential issues or areas for improvement.
Working with collections
To illustrate how easy is to work with collections I will describe the technical functionalities using the process called Peer Review.
When you must fill in a form and then save the content into a collection I suggest the following solution:
Data model: You have 2 entities Main Process entity called mPER and an entity mPERFinding. The latter has 2 relations with the former: these two are one-to-one (Finding) and one-to-many(Findings) as seen in the picture below.
The first relation is used to create the form where the user inputs the data.
The second one is to store the data each time the user completes the form.
<mPER.kmPERFinding.mPER> = <mPER>;
I had situations in the past where I was required to send a notification directly from an expression. After some trial and error, I managed to find a way. Here is an example of how to send a notification directly from an expression. The first thing I did was to create a library rule. The purpose is to have all the code in one place, in case I need to make any changes down the road. Otherwise, I will have to replicate the change in all the expressions where I’ve used the email method.
Content
Editable table with row validation
Table Functionality
Categories
Credential in Bizagi
Credential vs Me.Case.WorkingCredential
The important thing to consider when deciding to choose between these two functions is the CONTEXT: are you using this function in an ongoing case or outside of a case like Queries, Summary forms, Global forms etc?
- Use Credential, when it is required to use the information of the currently logged-in user in Query, Summary or Global forms etc (i.e., without context).
- Use Me.WorkingCredential, when it is required to use the information of the current user allocated to the current task in Process forms or expressions (i.e., with context).
Categories
Working with XMLs
Content
EntityManagerSOA web methods
