Installation and Configuration

By default, after an installation of the Business or Enterprise Edition of KonaKart, the ERP Integration features will be disabled so that no integration will occur.

A number of components need to be configured correctly in order for the ERP Integration features to enabled.

Incoming Message Processor

This processor should be started and configured in the web.xml file of the konakartadmin webapp. The following is an example of this section of the web.xml file that has been uncommented:


<!-- Incoming Message Processor -->
<servlet>
	<description>Servlet that reads an MQ queue looking for incoming messages</description>
	<servlet-name>ERPIncomingMsgProcessor</servlet-name>
	<servlet-class>com.konakartadmin.servlet.ERPIncomingMsgProcessor</servlet-class>
	<load-on-startup>200</load-on-startup>
</servlet>
<!-- End of Incoming Message Processor -->

The ERP Incoming Message Processor uses the following parameters for initialisation. These are defined in the konakartadmin.properties file.

The konakart.engineMode (this is the engine mode), konakart.customersShared , konakart.productsShared and konakart.categoriesShared are used when the incoming message processor creates engines to process the incoming messages from the ERP system. It's essential that these values match the rest of the KonaKart system. In fact, the wizard installer should set these values correctly at installation time but this won't be the case if the system was installed manually.

The konakart.KKAdminIfImplClassName parameter gives you the opportunity to define an alternative Admin engine. This may be required if, for example, you need to run a custom admin engine to process the incoming messages.

The konakart.KKEngPropertiesFile parameter must contain the full path of the konakart.properties file. This is required by the KonaKart KKEngIf engine (which the incoming message processor creates) to operate correctly. Having a reference to a single copy of the konakart.properties file is designed to make the system as a whole easier to maintain.

Apache ActiveMQ

Messages from external ERP systems are communicated to KonaKart via the Apache ActiveMQ message queue. The incoming message processor reads the incoming messages from the message queue (the default queue name is KonaKart.ERP.Q ) and then processes the contents for KonaKart. Hence, it is essential that the Apache ActiveMQ message queue is correctly configured and enabled.

By default KonaKart expects a queue for each store called KonaKart.store1.Q (for store1) and KonaKart.store2.Q (for store2) which are used for sending messages to the respective store ERP systems. The remote ERP systems read messages posted on these queues.

Links need to be defined between the brokers to ensure messages are distributed correctly. These definitions are specified in the konakart.properties file for the embedded brokers in KonaKart and in the standard activemq.xml configuration files for the remote brokers..

An example of the network connection set-up to support these two queues is as follows (in the konakart.properties file for the embedded brokers in KonaKart):


# -----------------------------------------------------------------------------------
# Message Queue Configuration

konakart.mq.broker.uri   = tcp://localhost:8791
konakart.mq.username     = kkuser
konakart.mq.password     = prince
konakart.mq.orders.queue = KonaKart.Orders.Queue

konakart.mq.ERP.queue    = KonaKart.ERP.Q

# Extended Configuration for Network / Broker / Queue Configurations
# If these are set, by uncommenting, NetworkConnections are set up with the specified 
# statically-defined Queue and credentials

konakart.mq.connector.store1.uri = static:(tcp://localhost:61616)
konakart.mq.connector.store1.queue = KonaKart.store1.Q
konakart.mq.connector.store1.user = user_store1
konakart.mq.connector.store1.password = prince_store1

konakart.mq.connector.store2.uri = static:(tcp://localhost:61617)
konakart.mq.connector.store2.queue = KonaKart.store2.Q
konakart.mq.connector.store2.user = user_store2
konakart.mq.connector.store2.password = prince_store2

The Extended Configurations are required to set up the queue connections in the embedded broker that runs by default inside the konakart webapp.

Similar network connection configurations will be required in other Apache MQ brokers you have in your network topology. These will be defined in the activemq.xml files for each broker. You will need to define network connections like these:


<networkConnectors>
    <networkConnector name="NC-Store1-To-KK1" 
                      uri="static:(tcp://localhost:8791)" 
                      staticBridge="true" 
                      userName="user_store1" 
                      password="prince_store1" 
                      conduitSubscriptions="false">
        <staticallyIncludedDestinations>
            <queue physicalName="KonaKart.ERP.Q"/>
        </staticallyIncludedDestinations>
    </networkConnector>
</networkConnectors>
        

The following configurations need to be set in the konakartadmin.properties file (this is located, by default, in the classes directory of the konakartadmin webapp):


# -----------------------------------------------------------------------------------
# Message Queue Configuration

konakart.mq.broker.uri   = tcp://localhost:8791
konakart.mq.username     = kkuser
konakart.mq.password     = prince
konakart.mq.orders.queue = KonaKart.Orders.Queue

# The Queue that the Incoming Message Processor reads to process messages from the 
# ERP system.  The default is KonaKart.ERP.Q
#konakart.mq.ERP.queue               = KonaKart.ERP.Q
konakart.mq.ERP.read.frequency.secs = 30
konakart.mq.ERP.read.timeout.secs   = 10

# This defines the number of seconds the Incoming Message Processor will sleep before 
# reading the queue for the first time.
#konakart.mq.ERP.initial.pause.secs  = 10

The polling frequency and timeout for the Incoming Message Processor can be set in the konakart.mq.ERP.read.frequency.secs and konakart.mq.ERP.read.timeout.secs properties respectively. Note that these quantities are specified in seconds.

The initial pause before reading the Incoming Message Queue for the first time can be set in the konakart.mq.ERP.initial.pause.secs property. This can be useful to delay the commencement of the queue reads until other parts of the system (in other webapps) are up and running. It's not critical to delay the start of the reads but it can stop connection failure exceptions at start-up as different parts of the system start-up at slightly different times.

The konakart.mq.ERP.queue property defaults to KonaKart.ERP.Q so in most cases this can be left commented out.

Please refer to the Message Queue Set-up section of this User Guide for more information on enabling and configuring Apache ActiveMQ for KonaKart.

ERP Integration - Configuration Parameters

The ERP Integration can be configured to meet your requirements by editing a set of configuration parameters that are made available on a panel under the Configurations section of the KonaKart Admin Console.

The panel is named ERP Integration and contains the following parameters:

KonaKart ERP Integration Parameters

The title of each variable has float-over help text to provide an explanation of the use and purpose of each parameter. Note that the variables must be set for each store.

As with other panels in the KonaKart Admin Console more information can be found by clicking on the Help icon on the panel.

For each store you must define two log directories, one for incoming messages that have been processed correctly and one for messages that have failed for some reason.

If an email address is entered for failed messages, every time a failed message log is produced, it will be emailed to this address as a log.txt attachment. Note that the address must be that of a person registered in the KonaKart system. The velocity template for the failed message log email is defaulted to ERPIntegrationErrorNotification_en.vm which is the template available in the kit. Each store may have a different template.

The exportInvoice message from the ERP system may or may not contain an invoicePath attribute. If this attribute is left empty then KonaKart expects the ERP Invoice Path configuration variable to contain the path of the directory where the PDF Invoice files may be found.

The velocity template for the email sent to customers containing the invoice as an attachment is defaulted to ERPIntegrationOrderInvoice_en.vm which is the template available in the kit. Each store may have a different template.

ERP Integration - OrderIntegrationMgr

In order for messages to be sent to the ERP system at appropriate times, it is necessary to make modifications to the OrderIntegrationMgr. These will be added to the OrderIntegrationMgr from v8.3.0.0 of KonaKart but you will need to merge these changes into your version of the OrderIntegrationMgr if you have previously made changes to it and are upgrading. (Note the addition of the calls to exportOrder in changeOrderStatus and saveOrder).

ERP Integration - Logging

In order to gain visibility on the ERP Integration processing within KonaKart the following log flags can be useful:


<!-- KonaKart ERP Integration -->
<Logger name="com.konakart.bl.ExportMgrEE" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakart.io.bl" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakartadmin.bl.AdminImportMgrEE" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakartadmin.bl.ERPQueueReader" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakartadmin.bl.AdminServletMgrEE" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakartadmin.servlet.ERPIncomingMsgProcessor" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<Logger name="com.konakartadmin.servlet.ERPIncomingMsgProcessor" level="DEBUG" additivity="false">
	<AppenderRef ref="STDOUT"/>
</Logger>
<!-- End of KonaKart ERP Integration -->

To monitor messages in the Active MQ queues you can use any compatible queue monitoring tool such as the one provided by hawtio (see http://hawt.io/ for more information).