Posts

Showing posts from June, 2025

Mulesoft -- Persistent Queues, Batch Job Queues, Object Store V2(OSV2) , Persistent Object Store, Non-Persistent Object Store in CloudHub 1.0

  In MuleSoft CloudHub 1.0, persistent queues and batch job queues are mechanisms to ensure reliable message processing and handle large datasets asynchronously. They are stored and managed differently but work together to provide scalability and reliability . Persistent Queues : Persistent queues in CloudHub 1.0 are used for reliable message delivery across Mule applications, particularly for VM (Virtual Machine) connectors or when distributing workloads across multiple workers. They are backed by CloudHub’s Cloud Queue Storage (CQS) , which uses Amazon SQS under the hood for persistence. When enabled in the Anypoint Runtime Manager (via the "Persistent Queues" checkbox) , all VM queues in the application are stored persistently in CQS, overriding any transient queue settings in the Mule configuration. Data in persistent queues is stored in the same region as the worker (e.g., AWS SQS in the deployed region) and survives worker restarts or crashes, ensuring zero mes...

Mulesoft - Transports(Connectors) Supporting Transactions

In MuleSoft, transactions ensure reliable message processing by providing atomicity, consistency, isolation, and durability (ACID) properties. Transactions are supported by specific transports (or connectors) in MuleSoft that allow for transactional behavior, such as committing or rolling back operations in case of success or failure   MuleSoft transports that support transactions are typically those that interact with systems capable of transactional processing, such as databases, message queues, or file systems. The following transports/connectors support transactions : JMS (Java Message Service) Connector Database Connector VM (Virtual Machine) Connector Non-Transactional Transports : Transports like HTTP, FTP, SFTP, or Email do not support full ACID transactions.

Mulesoft- Appropriate interface/data technology and interface definition language for all integration interfaces - soap ,rest and file

  SOAP (Simple Object Access Protocol) SOAP is a protocol for exchanging structured information in a platform-independent manner, typically over HTTP, using XML. Transport : HTTP/HTTPS (most common), SMTP, or TCP for specific use cases. Data Format : XML (mandatory for SOAP messages). REST (Representational State Transfer) REST is an architectural style for designing networked applications, relying on stateless, client-server communication, typically over HTTP. Transport : HTTP/HTTPS. Data Format : JSON (most common due to its lightweight nature), XML, or plain text. File-Based Integration File-based integration involves exchanging data via files (e.g., CSV, JSON, XML) over protocols like FTP, SFTP, or shared file systems. Transport : FTP/SFTP for secure file transfer. Data Format : CSV: For tabular data, widely supported but lacks schema enforcement. JSON: For structured, hierarchical data, lightweight and flexible. XML: For complex, schema-driven data, common in legacy sys...