Add-ons FAQ¶
This document touches on key concepts in the Lime CRM echo system that you need to be aware of when working with any kind of customizations in a solution. In order to keep information centralized and easier up-to-date, the documentation of add-ons and packages is based on this knowledge.
Please make sure to read the add-on's own documentation for all the specific information. We have all the different add-ons documentations linked here.
What is a solution, package and add-on?¶
Solution and package are both technical terms for what kind of customization you can do. Read all about their details and differences on this page.
We call something an add-on if it is sold as a product. An add-on technically consists of a python package (limepkg) and/or a LIP package. What that consists of depends on which components it uses, e.g. web components, custom endpoints, data structure, LBS app etc.
How can I add a package as a dependency to a solution?¶
The install process is documented here. The exact name of the dependency needs to be provided in the package documentation. Remember that an add-on can consist of more than a package, so make sure you cover all the installation steps in the add-on's own documentation.
How can I install a solution on-premise?¶
Check out this section for that.
What are the different kinds of configuration?¶
Runtime configuration¶
This is configuration that can be applied without restarting any services (during runtime). Common use cases for it are visual effects or mapping an integration to the Lime CRM database structure. You can therefore
head to Lime Admin/ Administrator Pages, which you can access as an admin from the webclient's account menu or via this URL: https://<DOMAIN>/<APP-NAME>/webadmin
Application configuration¶
This is configuration that affects one application in the environment. Read this section
for more details. As explained there, on-premise this configuration is done via an application_config.yaml file.
For cloud customers go to their application in CAFE and the "Config" tab.
Environment configuration¶
Lastly, there is configuration for each service on the platform, that therefore affects the entire environment. For cloud customers this is maintained by Lime Technologies' DevOps team. For on-premise solutions you can find more information here.
What are LIP packages?¶
LIP is a tool to adjust your Lime CRM database structure to extra requirements of a customization or add-on, as well as handle desktop client components, e.g., LBS apps, Actionpads or VBA modules. You can find a documentation for it here.
What is Lime Bootstrap?¶
Lime Bootstrap (also known as LBS) is a web framework for the Actionpad in the desktop client, so you can build your own customization. You can get further information on the topic here.
Security¶
Object Access¶
With the concept of object access you can define users permissions in great detail. Please check out this page for more on the topic.
API user¶
Many third party integrations communicate with Lime CRM via our REST API and rely therefore on an API key. To create one, create a user of type integration in LISA and generate an API key for that user. When communicating with the API ensure that the key is included in the header of each request like this:
curl --location --request <METHOD> 'http://URL/TO/THE/ENDPOINT' \
--header 'x-api-key: <API KEY>'
What are common approaches for troubleshoots?¶
Often when something isn't working it's due to a certain request that returns an error. The first approach should always be to find more information about that. Therefore open the DevTools of your client and look for the failed request. Here an example for the webclient:
The URL of the request should give an idea of the responsible component (core platform or which package) and an error message, which can help you to figure out whether or not a misconfiguration on your side could be the cause of the problem. If that's not enough information (e.g. in the case of a 500 error code) you should look for logs. The fact that you see a failed request means that it had to be processed by the webserver, so that's the service for which you want to see the logs for.
The more difficult cases are when you notice that one of the background services is acting out. Some common examples
- you started an async task, but it keeps on pending (-> taskhandler)
- you added a new object and can't find it in the global search (-> search-indexer)
- your custom event handler isn't executed (-> eventhandler)
Then you need to look for logs of that specific service.
Log files on-premise¶
Similarly to the environment config files the logs are located per service on the platform.
For Windows, the location is %programdata%\Lundalogik\LIME Pro Server\<service name>\logs.
For Linux, the location is /etc/lime/<service name>, such as: /etc/lime/Webserver/logs
Log files in Cloud¶
In cloud, logs are organized and accessible via Kibana. Open the menu in the left top corner and go
to "Discover" in the "Kibana" section. Before you start your search request adjust the time frame on the right, as well as adding the field
message (on the left)
Search by request¶
To find logs to the failing request example above you want to search for the request's URL and response like this
message : "<APP-NAME>/limepkg-kpi/kpi-aggregated/" and response : 500
Once you found that request, expand the document, copy the trace_id and change the search query to this
trace_id : "Root=<GENERATED ID>"
Now you get all log entries that are related to that one request.
Search by service¶
If you only know which service is causing the problem, you need to first figure out the hostname of the service docker container.
Therefore search for a request like the one above, but add appserver as job filter like this:
message : "https://<APP-PREFIX>.lime-crm.com" and job: appserver
Expand the details of the first log and look for the docker.hostname, which follows the following pattern: appserver-<hash-for-your-application>.1.<random-hash>.
Copy the docker hostname, change the service, keep the first hash and replace the second with a wildcard. If you're e.g. interested in all taskhandler
logs your filter should look like this:
docker.hostname : "taskhandler-<hash-for-your-application>.1.*"