This is one of the data gathering methodologies and recommendations for functional performance improvement. The full list is defined in the Functional Performance Recommendations topic here.
Business rules allow extension of the STEP functionality with customer-specific business logic. Business rules provide a flexible way to tailor the core functionality in a very precise manner and can be tied to, e.g., bulk updates, events, imports and IIEPs, approval processes, workflows, Web UI screens, etc.
Important: The system load of the business rule execution can have effect on the performance of STEP. Running a lot of complex business rules degrades performance while STEP is processing the business rules.
The available types of business rules, and the purposes for which each is optimized, are defined in the Business Rules topic in the Business Rules documentation here.
Details about where business rules can be used are defined in the Using Business Rules in STEP topic in the Business Rules documentation here.
Optimizing performance in business rules involves the following:
- Business Rule Analysis (here)
- Business Rule Elements to Use (here)
- Business Rule Elements to Avoid (here)
Extending STEP Functionality
If the business rule recommended practices have been implemented, and additional performance improvement is required, consider the following additional ways to extend STEP functionality.
|
Scripting API |
Allows customers and partners to expand STEP functionality with JavaScript Business Rules. Involves a low level of customization and extended functionality. |
|
Extension API |
Allows customers and partners to extend STEP functionality with development of plug-ins and components. Involves a moderate level of customization and extended functionality. |
|
Custom Extensions |
Allows Stibo Systems to extend STEP functionality with development of custom extensions. Involves a high level of customization and extended functionality. |
Using a Java extension can sometimes improve performance over a JavaScript business rule.
For example, this provides the ability to develop a custom extension instead of executing many complex business rules on import of data.
Note: Only cases where extreme amounts of logic are executed should be considered for this solution. In such cases, consider why it is necessary to run such complex logic.
The possible benefits of using a custom extension include:
- Event batching is used by the processor to ensure that business logic is executed exactly once per product per batch, even if multiple imports were executed for a single product.
- Optionally, the example plugin uses the parallel processing framework to maximize performance. This can potentially allow a ‘strict’ transaction endpoint to still benefit from parallelization in that rule execution can be multi-threaded while still ensuring data integrity.
- Resolve optimistic locks and deadlocks in cases where the locks are caused not by the import itself, but by logic that accesses and writes to objects shared among parallel import processes.
A common example of this occurs with tree structures. If parallel imports are executing on children of a common parent, each of which executes business logic causing an update to the parent, the result is deadlocks and sever performance degradation.
Another performance-related issue with this pattern is that the business logic is executed once per child. However, if the import logic is changed to republish the parent to the event queue instead of each child, event batching will result in a single update to the parent object, regardless of the number of children imported.
- The same concept can be applied using an OIEP configured with a business rule pre-processor. Execute import business logic in the pre-processor, then discard the event so that no exports are produced by the endpoint. Since endpoints do not use multi-threading while executing the pre-processor, the execution time may be longer than if a custom extension is used.
This solution also has some consequences:
- There will be a delay between importing data onto the object, and the business rule running. If timing is an issue, consider other options.
- The object cannot be inspected in both its previous and current form as easily, the business rules running in such a processor will have less information available than the same rule running during import.