Messages

But I had to download different .jar than konakart jars in /lib, such as an older version of wss4j (1.5.1, instead of 1.6).

For others reading this I just want to point out that there should be no need to change the wsdl4j-1.5.1.jar (if this is the jar you mean) and no need for any additional jars in order to compile or run.   The default installation will use the provided jars to create client stubs successfully from the WSDL.   If you use the provided build.xml and follow the User Guide it should work fine.

Hence I don't know what you're referring to Cyril or what is different about your environment.

Perhaps you are referring to a different jar?   You mention wss4j but we don't include that with KonaKart anyway.


Note again that the recommended approach is to use the KKWSEng engine rather than creating AXIS client stubs from the WSDL and writing your own AXIS client-side code because in a java environment it's significantly easier just to instantiate KKWSEng which implements KKEngIf (just like the KKEng POJO engine does) and takes care of all the SOAP plumbing for you automatically.
 
Indeed, the idea is that you write your client side code against the KKEngIf (the "storefront" engine interface) and then later you can decide which implementation to use with your client-side code (selecting from POJO, RMI, SOAP or JSON by name at runtime).   If you write your own AXIS code you cannot benefit from this flexibility.

You'll find life a lot easier if you create an engine using code like this:

(see "C:\Program Files\KonaKart\java_api_examples\src\com\konakartadmin\apiexamples\BaseApiExample.java")

Code Select Expand

KKAdminEngineMgr kkAdminEngMgr = new KKAdminEngineMgr();
AdminEngineConfig adEngConf = new AdminEngineConfig();
adEngConf.setMode(engineMode);
adEngConf.setPropertiesFileName(DEFAULT_KONAKARTADMIN_PROPS_FILENAME);
adEngConf.setAxisClientFileName(DEFAULT_KONAKART_AXIS_CLIENT_PROPS_FILENAME);
adEngConf.setStoreId(storeId);
adEngConf.setCustomersShared(custShared);
adEngConf.setProductsShared(prodShared);
adEngConf.setProperties(properties);

/*
  * This creates a KonaKart Admin Engine by name using the constructor that requires an
  * AdminEngineConfig object. This is the recommended approach.
  */
setEng(kkAdminEngMgr.getKKAdminByName(engineClass, adEngConf));


-Merry Christmas :-)

The section in the User Guide "under Configuration of Messages") explains where in the Admin App you can modify the "USE_DB_FOR_MESSAGES" configuration variable and the process for loading messages successfully.

The default state of the kk_msg table is for it to be empty and that doesn't cause the Admin App to crash so I'm not sure what has happened to cause that.

You need to load the messages into the db first, then set the "USE_DB_FOR_MESSAGES" configuration variable then all will be fine.

Maybe you were getting problems because you set the config variable before you loaded the messages and hence KonaKart couldn't find any messages to use...

Anyway...  I'm glad you worked it all out on your own in the end.

That's right, the Admin App uses GWT.

You can add your own special functionality in the custom panels but you can't change the functionality of the standard KonaKart panels.

What did you want to do exactly?

So it worked when you first installed it, then you moved it and then it didn't work?

What's the difference between where it was at first and where you moved it to?

It sounds like you need to look at custom attributes and custom attribute templates.  These are powerful in that they allow you to define an unlimited number of custom attributes for a product.   Check out these features in the User Guide.

Alternatively you might just want to use a regular custom field but only refer to it for a certain category?

Your client is correct.  There is currently a restriction there in the Admin App which only allows 1000 Admin App users to appear in that list.

You're right that it's a high number but in certain environments I can see that in extreme cases this could be a limitation.

Since you have a support contract with us, please can you get your authorised contact person to contact us by email so that we can discuss a solution to this with you.

I just want to reassure you that KonaKart works fine with MS SQL Server - we test on many versions including 2008 and 2012.   You just need to figure out why your MS SQL Server isn't accessible to KonaKart.   Can't you figure out what's wrong by looking at the exceptions?  Does it show a SQL State error that you can look up in Google?

Thanks for sharing those translations!

It's often a good idea to use the installer to specify your DB credentials because the connection is checked during the wizard process.   Once the installer checks the credentials are OK and proceeds with the rest of the installation it will set these values in your properties files automatically.

The Reward Points functionality is available in the Enterprise Extensions version of KonaKart:

http://www.konakart.com/product/community-or-enterprise

Perhaps you are using the Community Edition?

To make the Export button invisible on the Orders panel go into the privileges view for the relevant role and tick the checkbox that shows the "If set Export button not shown" - it's on the Orders Panel and it's the 4th custom field.

Note that there is a Customer Orders panel that also has the Export button.  You may wish to configure that one in a similar fashion?

For any others just move your mouse over the checkboxes that are marked green to find out what special configurations can be applied.  They usually apply to making various buttons invisible.

You have to do that by defining the Role Privileges - it's part of the Role-Based security.

To remove the Bookings button on the Products panel you have to remove access to the "Bookings For Product" panel for the required role.   To do that you move that panel from the Assigned Panels to the Available Panels and save.

Log in again and the Bookings button should not be visible.


Messages files are for messages - typically used for I18N.

If you generate your classes from the WSDL there is no way they will pick up our default values when instantiated.

This is one of a few reasons why it's a whole lot easier just to instantiate a KonaKart web services client engine (eg com.konakartadmin.ws.KKWSAdmin etc) instead of creating your own classes from the WSDL.

Check the User Guide for the recommended approach on this.

I would only use my own generated classes from WSDL if I was not using java on the client side.   You can do this, but you have to understand that you won't get the default values set in your objects... plus you have to do all the SOAP plumbing yourself (which our engines take care of).

By contrast, if you use KKWSAdmin and KKWSEng the code you write is absolutely identical to the code you would write against KKAdmin and KKEng...   so the javadoc is identical etc etc.. so much easier.

Try clicking on the blue question mark on almost all panels.