Hazelcast + Ignite

when deploying docuflow behind a load balancer with multiple instances running, distributed caching and locking mechanisms become essential for maintaining data consistency and preventing race conditions without a distributed solution, each docuflow instance would operate with its own independent cache and locking mechanism this independence can lead to potential conflicts for example, if one docuflow instance modifies data in sap via saplink, another instance might be completely unaware of the change this lack of awareness could result in the second instance using stale data or causing processing errors due to conflicting updates hazelcast and ignite address this problem by providing a shared, distributed cache and locking service this ensures that all docuflow instances behind the load balancer have a consistent view of data furthermore, operations, especially those interacting with external systems like sap, are synchronized correctly across all instances this synchronization guarantees reliable and predictable behavior in a high availability, load balanced environment document metadata caching (major performance improvement) in addition to distributed locking and general caching, docuflow selectively uses hazelcast and ignite to cache document metadata upon creation this means that when a document is created, its metadata is stored in the distributed cache subsequent retrievals of that document and it's metadata can then be served significantly faster from the cache, rather than requiring a potentially slower fetch from the underlying content repository (e g , filenet, documentum, box) it's important to note that this metadata caching is not universally applied to all document operations; it's strategically used in specific areas of the application to maximize performance gains confirm with your docuflow architect for more information on which specific operations utilize this metadata caching starting with docuflow version 6 8 0, both hazelcast and ignite are offered as options for distributed caching and locking this dual offering provides significant flexibility the two platforms have different strengths ignite boasts a broader range of in memory computing features beyond just caching and locking, while hazelcast is often considered simpler to deploy and manage this choice accommodates users who may already have existing hazelcast or ignite infrastructure or in house expertise it also allows for performance benchmarking in specific environments to determine which solution performs optimally the different licensing models (hazelcast has commercial options, whereas ignite is fully open source) also cater to varying budgetary and licensing preferences finally, offering two distinct technologies reduces reliance on a single vendor and provides a fallback option, enhancing the overall robustness of the docuflow deployment ultimately, users can select the best fit for their particular needs and avoid vendor lock in i introduction distributed caching and locking the enterprise connector utilizes distributed caching and locking mechanisms to improve performance and ensure data consistency across multiple instances (nodes) of the connector, especially in high availability or clustered environments you can choose between two primary providers for these features hazelcast a popular in memory data grid that provides distributed caching, locking, and other features ignite a more comprehensive in memory computing platform that also offers distributed caching, locking, and advanced features like compute grids and sql support this document explains how to enable and configure either hazelcast or ignite within the config properties file you should generally choose only one; do not enable both simultaneously ii enabling and disabling hazelcast/ignite the most fundamental configuration is enabling or disabling these features hazelcast enabled controls whether hazelcast is used yes enables hazelcast no (or any other value, or if the property is missing) disables hazelcast ignite enabled controls whether ignite is used yes enables ignite no (or any other value, or if the property is missing) disables ignite example (enable hazelcast, disable ignite) hazelcast enabled=yes ignite enabled=no example (disable hazelcast, enable ignite) hazelcast enabled=no ignite enabled=yes example (disable both default behavior if neither is specified) \# hazelcast enabled is not present \# ignite enabled is not present iii hazelcast configuration if hazelcast enabled=yes, the following properties are used to configure hazelcast basic cluster setup hazelcast groupname the name of the hazelcast cluster all connector instances that should work together must use the same group name this is crucial for them to discover each other and form a cluster choose a descriptive name, but avoid spaces or special characters example myconnectorcluster hazelcast grouppassword a password for the hazelcast cluster all connector instances must use the same password to join the cluster this adds a basic layer of security, preventing unauthorized nodes from joining example mysecurepassword hazelcast networkipaddress the primary ip address or hostname that this connector instance will use for hazelcast communication this is how other nodes will find this one if running on a single machine (for testing), you can often use 127 0 0 1 (localhost) in a production environment, use the actual ip address of the machine, preferably a static ip do not use 0 0 0 0 (which binds to all interfaces) unless you fully understand the implications example 192 168 1 100 hazelcast networkipaddress2 an optional second ip address or hostname this can be used for redundancy or if the connector instance has multiple network interfaces if not needed, leave it blank or remove the property example 192 168 1 101 hazelcast networkport the port hazelcast will use for communication the default is usually 5701 you generally don't need to change this unless there's a conflict with another application all nodes in the cluster must use the same port example 5701 if you change it, make sure the new port is open in your firewall hazelcast ispublic indicates whether the hazelcast instance is accessible from outside the local network (e g , on the public internet) this has significant security implications yes the instance is publicly accessible extreme caution is required ensure strong security measures (password, potentially tls/ssl) are in place no (or blank, or property missing) the instance is only accessible within the local network this is the recommended setting for most deployments hazelcast and saplink locking (saplink usehazelcastlocks) this property, if set to yes, tells the connector to use hazelcast's distributed locking mechanism for saplink operations this is important for ensuring data consistency when multiple connector instances are interacting with sap yes enable hazelcast based locking for saplink no (or blank, or property missing) use the default locking mechanism (which might not be distributed) important if you have multiple connector instances and are using saplink, you should enable either hazelcast or ignite locking example hazelcast configuration hazelcast enabled=yes hazelcast groupname=myconnectorcluster hazelcast grouppassword=mysecurepassword hazelcast networkipaddress=192 168 1 100 hazelcast networkipaddress2= hazelcast networkport=5701 hazelcast ispublic=no saplink usehazelcastlocks=yes hazelcast vnetpeering=true iv ignite configuration if ignite enabled=yes, the following properties configure apache ignite basic cluster setup ignite internalip the primary ip address or hostname that this connector instance will use for ignite communication this is analogous to hazelcast networkipaddress example 192 168 1 100 ignite internalip2 an optional second ip address or hostname for redundancy or multiple network interfaces similar to hazelcast networkipaddress2 example 192 168 1 101 ignite clustername specifies the name of the ignite cluster similar to hazelcast groupname, all nodes in the same cluster must have the same name default defaultclustername (if the property is missing) example myignitecluster ignite ssl/tls configuration (optional but recommended) ignite can be configured to use ssl/tls for secure communication between nodes this is highly recommended in production environments ignite sslenabled enables or disables ssl/tls for ignite true enable ssl/tls you must also configure the keystore and truststore false (or any other value, or property missing) disable ssl/tls not recommended for production ignite keystorepath the absolute path to the java keystore (jks) file that contains the connector's ssl/tls certificate and private key this is required if ignite sslenabled=true example /opt/ewave/connector/config/ignite keystore jks ignite truststorepath the absolute path to the java truststore (jks) file that contains the trusted certificates of other nodes in the cluster, or the certificate authority (ca) that signed those certificates this is required if ignite sslenabled=true example /opt/ewave/connector/config/ignite truststore jks ignite ssl keystore password the password for the keystore specified by ignite keystorepath ignite ssl truststore password the password to the trustore specified by ignite truststorepath ignite and saplink locking (saplink useignitelocks) this property, if set to yes, tells the connector to use ignite's distributed locking mechanism for saplink operations, similar to the hazelcast equivalent yes enable ignite based locking for saplink no (or blank, or property missing) use the default locking mechanism example ignite configuration (with ssl/tls) ignite enabled=yes ignite internalip=192 168 1 100 ignite internalip2= ignite clustername=myignitecluster ignite sslenabled=true ignite keystorepath=/opt/ewave/connector/config/ignite keystore jks ignite truststorepath=/opt/ewave/connector/config/ignite truststore jks ignite ssl keystore password=keystorepassword ignite ssl truststore password=truststorepassword saplink useignitelocks=yes example ignite configuration (without ssl/tls not recommended for production) ignite enabled=yes ignite internalip=192 168 1 100 ignite internalip2= ignite clustername=myignitecluster ignite sslenabled=false # explicitly disabling clearer than omitting saplink useignitelocks=yes v key considerations and best practices choose one use either hazelcast or ignite, not both ip addresses use static ip addresses for production environments to ensure consistent connectivity firewall ensure that the chosen ports (default 5701 for hazelcast) are open in your firewall between all connector instances security for hazelcast, always set a strong hazelcast grouppassword for ignite, strongly consider enabling ssl/tls (ignite sslenabled=true) and configuring the keystore and truststore if hazelcast ispublic=yes, be extremely careful about network security testing thoroughly test your configuration in a non production environment before deploying to production verify that the connector instances can discover each other and form a cluster you can often check the logs for messages related to cluster formation keystore/truststore management if you use ignite with ssl, carefully manage your keystore and truststore files ensure they are properly generated, securely stored, and have appropriate passwords absolute paths use absolute, not relative paths for ignite keystorepath and ignite truststorepath saplink locking enable distributed locking (either hazelcast or ignite) if you have multiple connector instances interacting with sap via saplink this comprehensive guide should enable your administrator to configure hazelcast or ignite effectively within the config properties file remember to consult the official documentation for hazelcast and apache ignite for more advanced configuration options and troubleshooting