Salesforce

Architectural Considerations (Magic xpi 3.x)

Printable View
« Go Back

Information

 
Created ByKnowledge Migration User
Approval Process StatusPublished
Objective
Description

Architectural Considerations (Magic xpi 3.x)

The Magic xpi project architecture can have a major impact on the performance of the Magic xpi Server. These are some of the architectural issues that you should consider:

  • If multiple Magic xpi Servers are executing on the same machine, you should use the optimal number of concurrent flows executed by a single Magic xpi Server.

  • Multiple Magic xpi Servers can be executed on different machines.

  • The internal database can be located on the same machine as the Magic xpi Server, or on another machine.

  • External project I/O performance. This includes:

    • Connectivity to external applications, such as middleware, HTTP, and Web Services

    • Bottleneck processing due to external application performance and limitations

    • Communication speed

Note:

Proper selection and tuning of these applications, as well as the communication channel, can improve performance.

    • Magic xpi logging configuration

  • Usage of Remote Services (Activity logging, ODS, PSS) and Routing are additional architectural solutions that may improve overall performance.

Note:

Limiting information collected by the Server and written to the internal database, such as the collection of statistics and the level of activity logged, will improve the Magic xpi Server throughput.

  • The performance of your process is derived from the load and the response time definitions and limitations. Based on these definitions you might need to take these actions:

    • Split your process into sub-processes.

    • Use the loosely coupled concept to process the received information as quickly and efficiently as possible. For example, do not hold a thread to call a remote application or database, but invoke a new flow that will do the processing, and when finished will call back the main flow.

    • Switch from a synchronous to an asynchronous processing mode.

    • Spread your project over several servers.

Tip:

When splitting a synchronous process into several asynchronous ones, you can use the Wait for completion service to proceed with the main processing.

Related Topics

Loosely-Coupled Architecture

Licensing Considerations

Security Issues

Error Management

Performance Guidelines

Reference
Attachment 
Attachment