-
Kernel
-
Plugins
-
Release Notes
Kernel
Plugins
Release Notes
This chapter may be skipped at first time of using the system. |
Система BGERP является в первую очередь платформой, поэтому значительный эффект от её применения достигается путём реализации различного рода расширений под специфику пользователя.
BGERP предоставляет сразу несколько уровней для расширения либо модификации стандартной логики. Способы перечислены в порядке возрастания сложности и функциональности. Рекомендуемая практика - переход от простого к более сложному.
Very many things in our product can be changed using configurations, which are well-documented and stable after version updates. Use JEXL scripts for more flexibility.
Develop own Custom plugins using Java, JSP and full-featured IDE.
JEXL - язык коротких выражений.
Используется для написания в конфигурации макросов условных выражений, гибкого вычисления небольших строк. Помимо операторов, описание которых доступно по ссылке в конце раздела, язык поддерживает обращение к функциям Java - объектов, переданных на вход обработчика в зависимости от условий.
При необходимости выражения могут быть многострочными, при этом результат (если он есть) возвращается оператором return. Пример многострочного скрипта для простого обработчика событий процесса:
In JEXL processor always passed the variables:
u - static context of class ru.bgcrm.util.Utils - for static methods calls;
tu - static context of class ru.bgcrm.util.TimeUtils - for static methods calls;
tc - static context of class org.bgerp.util.TimeConvert - for static methods calls;
su - static context of class org.apache.commons.lang3.StringUtils - for static methods calls;
сu - static context of class org.apache.commons.collections.CollectionUtils - for static methods calls;
fu - object of class org.apache.commons.io.FileUtils for calling static methods;
log - object of class org.bgerp.util.Log, allows debugging using log.debug and other calls;
NEW_LINE - line break;
NEW_LINE2 - two line breaks.
Variables for process handling:
user - object of class ru.bgcrm.model.user.User - текущий пользователь;
up or userParam - object of class ru.bgcrm.dao.expression.ParamExpressionObject - параметры текущего пользователя;
p or process - объект of class ru.bgcrm.model.process.Process - изменяющийся процесс;
pp or processParam - object of class ru.bgcrm.dao.expression.ParamExpressionObject - параметры изменяющегося процесса;
processLink - object of class ru.bgcrm.dao.expression.ProcessLinkExpressionObject - привязки изменяющегося процесса;
conSet - object of class ru.bgcrm.util.sql.ConnectionSet - соединения к БД;
form - object of class ru.bgcrm.struts.form.DynActionForm - данные по запросу к серверу;
все переменные контекста из ru.bgcrm.servlet.filter.SetRequestParamsFilter;
object of class ru.bgcrm.dao.expression.ProcessChangeExpressionObject передаётся как контекст функций по-умолчанию, т.е. все его функции можно вызывать в скрипте без префикса параменной с точкой.
Регулярные выражения позволяют гибко описывать шаблоны строк.
Описание строк осуществляется путём подстановки определённых макросов, обозначающих части строки либо символы определённого типа.
Например:
(342) - это символы 342 следующие один за другим;
3\d2 - это 3 затем любая цифра и 2;
342)|(559 - последовательность симоволов 342 либо 559;
44[2-8] - строки 442, 443, 444, 445, 446, 447, 448.
Расшифровка некоторых макросов:
а-b - на этом месте может располагаться симовол от a до b (в таблице символов);
[abc] - на этом месте может располагаться любой из символов a, b либо c;
abc - последовательное расположение символов a, b, c;
abc)|(def - на этом месте последовательно располагаются abc либо def, () - группа символов.
Ссылки:
http://www.opennet.ru/docs/RUS/perlre_man/ - регулярные выражения Perl, практически идентичны Java.
http://j2w.blogspot.com/2008/01/java.html - регулярные выражения Java.
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html - спецификация на английском.
Log4j - библиотека логирования для Java. Настройка логирования производится в файле log4j.properties, изменение файла можно производить при работающем приложении. Вид файла при установке системы:
// PzdcDoc snippet of: 'log4j.properties', lines: 1 - 92
# factory for making loggers out of the configuration with additivity=false
log4j.loggerFactory=org.bgerp.util.log.LoggerFactory
# libraries logging
log4j.rootLogger=WARN, file, session
# prevent messages "Invalid chunk starting at byte [0] and ending at byte [0] with a value of [null] ignored"
log4j.logger.org.apache.tomcat.util.http.Parameters=ERROR, file
# the application logging
# add ending ', out' appender when running inside IDE to see INFO output also in STDOUT
# or ', outa' to see all output in STDOUT
log4j.logger.ru.bgcrm=ALL, filew, file, filed, session
log4j.logger.org.bgerp=ALL, filew, file, filed, session
# only WARN messages
log4j.appender.filew=org.apache.log4j.RollingFileAppender
log4j.appender.filew.layout=org.apache.log4j.PatternLayout
log4j.appender.filew.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.filew.encoding=UTF-8
log4j.appender.filew.File=./log/bgerp.warn.log
log4j.appender.filew.Append=false
log4j.appender.filew.MaxBackupIndex=0
log4j.appender.filew.MaxFileSize=10MB
log4j.appender.filew.Threshold=WARN
log4j.appender.filew.filter.a=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.filew.filter.a.LevelToMatch=WARN
log4j.appender.filew.filter.a.AcceptOnMatch=true
log4j.appender.filew.filter.b=org.apache.log4j.varia.LevelMatchFilter
log4j.appender.filew.filter.b.LevelToMatch=ERROR
log4j.appender.filew.filter.b.AcceptOnMatch=false
# INFO, WARN, ERROR messages
log4j.appender.file=org.apache.log4j.RollingFileAppender
log4j.appender.file.layout=org.apache.log4j.PatternLayout
log4j.appender.file.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.file.encoding=UTF-8
log4j.appender.file.File=./log/bgerp.log
log4j.appender.file.Append=true
log4j.appender.file.MaxBackupIndex=5
log4j.appender.file.MaxFileSize=10MB
log4j.appender.file.Threshold=INFO
# DEBUG, INFO, WARN, ERROR messages
log4j.appender.filed=org.apache.log4j.RollingFileAppender
log4j.appender.filed.layout=org.apache.log4j.PatternLayout
log4j.appender.filed.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.filed.encoding=UTF-8
log4j.appender.filed.File=./log/bgerp.debug.log
log4j.appender.filed.Append=true
log4j.appender.filed.MaxBackupIndex=5
log4j.appender.filed.MaxFileSize=10MB
log4j.appender.filed.Threshold=DEBUG
# all messages
log4j.appender.filea=org.apache.log4j.RollingFileAppender
log4j.appender.filea.layout=org.apache.log4j.PatternLayout
log4j.appender.filea.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.filea.encoding=UTF-8
log4j.appender.filea.File=./log/bgerp.all.log
log4j.appender.filea.Append=true
log4j.appender.filea.MaxBackupIndex=5
log4j.appender.filea.MaxFileSize=10MB
log4j.appender.session=org.bgerp.util.log.SessionLogAppender
log4j.appender.session.layout=org.apache.log4j.PatternLayout
log4j.appender.session.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.session.Threshold=DEBUG
# info out, for running in IDE add it after 'ALL, file, session'
log4j.appender.out=org.apache.log4j.ConsoleAppender
log4j.appender.out.Target=System.out
log4j.appender.out.layout=org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.out.Threshold=INFO
# all stdout, for debuging in IDE connect it to newly added loggers
log4j.appender.outa=org.apache.log4j.ConsoleAppender
log4j.appender.outa.Target=System.out
log4j.appender.outa.layout=org.apache.log4j.PatternLayout
log4j.appender.outa.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
# sent mails
log4j.logger.ru.bgcrm.util.MailMsg=INFO, mail
log4j.appender.mail=org.apache.log4j.RollingFileAppender
log4j.appender.mail.layout=org.apache.log4j.PatternLayout
log4j.appender.mail.layout.ConversionPattern=%d{MM-dd/HH:mm:ss} %5p [%t] %c{1} - %m%n
log4j.appender.mail.encoding=UTF-8
log4j.appender.mail.File=./log/mail.log
log4j.appender.mail.Append=true
log4j.appender.mail.MaxBackupIndex=5
log4j.appender.mail.MaxFileSize=10MB
Сообщения в логе разделяются на уровни (в порядке возрастания): DEBUG, INFO, WARN, ERROR, FATAL. По-умолчанию настроен уровень INFO, т.е. выводятся информационные и ошибочные сообщения (INFO, FATAL, ERROR), отладка не выводится. Вывод осуществляется в файл log/bgerp.log, который обрезается на размере 10МБ с созданием отдельных файлов.
Samples, how to enable loggers wanted package or classes to log/bgerp.all.log in:
В конфигурационном файле возможно изменять формат информации в файле, фильтр по классам и другие параметры логирования.
To observe only the logs of the current user session, use Dynamic Log.
Ссылки:
http://artamonov.ru/2007/04/06/vvedenie-v-log4j/ - вводная статья на русском.
Custom application code has to be placed custom
directory in the project root.
Inside custom/src
placed regular Java code, including plugins plugins. PLUGIN_ID for those has to be prefixed by custom., e.g. custom.bitel. Respectively plugin files have to be stored under paths: custom/org/bgerp/plugin/custom/<some-name> .
That code has equal possibilities as the native application’s, can use API and connected libraries. After compilation Administration / Custom this code is persisted to lib/app/custom.jar
.
Custom Java classes are dynamically reloaded after each successfull compilation. For that all the Custom Java sources must be located in org.bgerp.plugin.custom package or its subpackages.
Although there is a Restart button available after successful compilation, it is not required. |
Subdirectory custom/webapps
is searched before webapps
from root directory and should be used for placing custom JSP and JS files. Both types are applied immediately after change.
Each file from the original webapps may be "replaced" for Web server. That can brake built-in functionality. |
In file custom/l10n.xml
has a special meaning for localization system, it allows to re-define each localized string in the system.
Additional third-party Java libraries, used in Custom solutions, must be stored in lib/custom
directory, as JAR files in lib/ext
are overwritten during libraries update.
Storing custom sources in a GIT repository allows you to track all made changes and always have backup copy of your work.
In order to store your custom code you have to create a custom GIT repository and add there permissions of developers, who do you trust. We kindly ask you to use open forks of the Custom GIT template repo: https://github.com/Pingvin235/bgerp-custom , hosted on GitHub. With that you share your experience with other customers.
Be sure that you are not hardcoded any confidential data in your Custom GIT. |
For creating your Custom GIT you have make the following steps.
Make a GitHub account if it you don’t have it and log in with it.
Open the template repo https://github.com/Pingvin235/bgerp-custom and press Fork button.
Rename the fork on Settings tab to bgerp-custom-<MyCompany>, using instead of <MyCompany> a wanted name. For example bgerp-custom-bitel as on the screen below.
Go to Settings / Collaborators and add your trusted developers using their GitHub accounts or e-mails.
Content of the directory may be stored using GIT and developed in full-featured IDE.
The custom
directory is ignored in the root directory of the project, and has to be checked out independently, e.g.:
git clone https://github.com/Company/bgerp-custom-company.git custom
A GIT URL can be taken from GitHub UI.
Once you did changes, run the commands for pushing them in custom
directory.
git pull --rebase && git add . && git commit -m "My changes" && git push
The same clone command has to be run in application directory, e.g.
git clone https://github.com/Company/bgerp-custom-company.git /opt/bgerp/custom
For checking out changes out of CUSTOM GIT may be used approach with DETACHED HEAD:
git fetch && git checkout origin/master
With CUSTOM GIT also can be used the same GIT workflow as for the main project’s code. Any change has to be placed in a separated branch.
Во всех данных примерах могут использоватся как классы из библиотек системы, так и custom.
Параметры runOnStart и createOnStart в конфигурации сервера. Указанные в них объекты классов создаются и запускаются для runOnStart при старте сервера.
<server>/admin/run.do?action=runClass&iface=<iface>&class=<className>&j_username=<user>&j_password=<pswd>¶m1=value¶m2=..
Где:
<server> - host and port of the server;
<className> - имя динамического класса;
<user> и <pswd> - логин и пароль пользователя BGERP, подробнее о запросах внешних систем;
<iface> - тип класса-обработчика, подробнее ниже.
При параметре <iface> равным event класс должен реализовывать интерфейс ru.bgcrm.event.listener.EventListener в который передаётся событие ru.bgcrm.event.RunClassRequestEvent. В противном случае класс может реализовать интерфейс java.lang.Runnable, который просто будет запущен.
Для запуска любого класса, статического или динамического в контексте сервера BGERP вызовите:
./erp.sh "runclass <class_name>"
Где <class_name> - полное имя класса с пакетом. Класс должен реализовывать интерфейс java.lang.Runnable.
Запуск в контексте сервера обозначает, что класс будет выполнен в рамках отдельного потока процесса сервера, получив доступ к соединению с БД, конфигурациям и другим объектам контекста. Результаты работы можно выводить в логи.
Для периодического выполнения класса необходимо использовать планировщик.
Все запросы на изменение данных в возвращают результат в JSON формате. Запросы выборки данных возвращают результат в HTML формате, однако возможно получение данных и в JSON формате, путём добавления в запрос параметра responseType=json.
Для прозрачной авторизации запроса сторонней системы логин и пароль пользователя могут быть переданы в запросе в HTTP параметрах запроса j_username и j_password соответственно. Параметр authToSession=0 в запросе указывает на хранение отсутствие необходимости в HTTP сессии. Настоятельно рекомендуется использовать его при запросах внешних систем, т.к. предотвращение создания HTTP сессий экономит память BGERP.
Пример запроса на получение данных во внешнюю систему в JSON формате (выборка по очереди процессов):
https://bgerp.company.com/user/process.do?action=queueShow&id=4&dateStatusStatus=10&status=10&status=9&status=13¤tUserMode=&group=7&sort=0&j_username=shamil&j_password=*****&responseType=json&authToSession=0
При изучении формата запросов и ответов возможно использование инструмента разработчика в браузере с отслеживанием запросов отправляемых браузером при работе пользователя в системе.
Another sample for retrieving user list. Notice the request parameter page.pageIndex=-1 for disabling pagination.
https://demo.bgerp.org/admin/user.do?action=userList&j_username=admin&j_password=admin&responseType=json&authToSession=0&page.pageIndex=-1
For complex data reading Plugin DBA with SQL queries is recommend you to use, an example:
https://demo.bgerp.org/admin/plugin/dba/query.do?query=SELECT%20id,%20title%20FROM%20user&j_username=admin&j_password=admin&responseType=json&authToSession=0&page.pageIndex=-1