Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA Enterprise SCADA BLT API Reference

Best practices when using the Business Logic Tier (BLT) Application Programming Interface (API)

Best practices when using the Business Logic Tier (BLT) Application Programming Interface (API)

The following sections outline the best practices when using the Business Logic Tier (BLT) Application Programming Interface (API).

  • A BLT component should complete quickly. Typically, a BLT component should complete in less than a second. If the execution time is not short and predictable, then a BLT component is probably not the right architectural choice.
  • A BLT component should not be called too frequently. Typically, a BLT component would be called no more than a few dozen times per second. There is overhead involved in authenticating and authorizing each BLT component call, which make it unsuitable for high throughput execution. If the BLT component needs to be called more often than suggested, reconsider the use of a BLT component.
  • Chaining BLT components together (that is, calling one BLT component from another) is possible, but it is not recommended as a general practice.   
  • If a BLT component needs to use PubSub or Microsoft SQL, then the BLT component is responsible for opening the connection using the correct security context for the BLT client and disposing of it appropriately when the connection is no longer required.
  • A BLT component call is a recommended way to trigger an action or make a request to a remote OASyS service from a local OASyS service (subject to the conditions and limitations previously listed).
  • Custom BLT components should be hosted in their own BLTHost instance, rather than in one of the baseline BLTHost instances. Isolating custom BLT components into a separate BLTHost makes them easier to debug.
TitleResults for “How to create a CRG?”Also Available in