gifts2017

Интеграция Java и 1С через .Net framework на примере Apache PDFBox

Опубликовал Сергей Карташев (Elisy) в раздел Программирование - Инструментарий

В сети Интернет мало информации по интеграции Java и 1С. Тем не менее, есть интересные Java-проекты, работу которых хотелось бы оценить внутри 1С. Apache PDFBox – один из таких популярных проектов. Так сложилось, что файлы pdf являются очень распространенными, а 1С не имеет хороших средств работы с данным форматом. Предложенный здесь способ состоит в том, чтобы через утилиту IKVM.NET перевести JAVA-библиотеку в .Net-сборку, а затем использовать эту сборку внутри 1С средствами интеграции.

Интеграция Java и 1С через .Net framework на примере Apache PDFBox

В сети Интернет мало информации по интеграции Java и 1С. Тем не менее, есть интересные Java-проекты, работу которых хотелось бы оценить внутри 1С. Apache PDFBox – один из таких популярных проектов. Так сложилось, что файлы pdf являются очень распространенными, а 1С не имеет хороших средств работы с данным форматом. Предложенный здесь способ состоит в том, чтобы через утилиту IKVM.NET перевести JAVA-библиотеку в .Net-сборку, а затем использовать эту сборку внутри 1С средствами интеграции.

Apache PDFBox– это библиотека Java для работы с PDF-документами. Позволяет выполнять операции: извлечение текста, печать PDF, слияние и разделение документов, преобразование в изображение, заполнение форм, создание PDF, проверка PDF/A, интеграция с Lucene Search Engine. В примере использована версия 1.8.2.

IKVM.Net – это виртуальная машина Java для Mono и .Net framework. IKVM.Net позволяет конвертировать библиотеку Java в сборку .Net и затем обращаться к библиотеке средствами .Net framework. IKVM.Net содержит много вспомогательных сборок, отвечающих за различные классы Java. В примере используется версия 7.2.4630.5.

Конвертация Jar в dll-сборку

На данном шаге предполагается, что IKVM.Net 7.2.4630.5 установлен на компьютере.

Перед конвертацией Jar-библиотеки в сборку .Net framework необходимо установить Java Runtime Engine и прописать переменную окружения JAVA_HOME:

JAVA_HOME C:\Progra~1\Java\jre6

Переменная окружения JAVA_HOME

Команда преобразования сборки имеет следующий вид:

ikvmc.exe -out:pdfbox.dll pdfbox-app-1.8.2.jar

На выходе получается сборка pdfbox.dll, зависящая от сборок:

IKVM.OpenJDK.Beans.dll
IKVM.OpenJDK.Core.dll
IKVM.OpenJDK.Jdbc.dll
IKVM.OpenJDK.Media.dll
IKVM.OpenJDK.Naming.dll
IKVM.OpenJDK.Security.dll
IKVM.OpenJDK.SwingAWT.dll
IKVM.OpenJDK.Text.dll
IKVM.OpenJDK.Util.dll
IKVM.OpenJDK.XML.API.dll
IKVM.Runtime.dll

На этом этапе виден недостаток способа, связанный с большим объемом совместно поставляемых сборок. PDFBox.dll занимает около 10 МБ, и вспомогательные сборки занимают около 18 МБ.

Выполнение простейших операций PDFBox внутри 1С

Запуск сконвертированной из JAVA сборки PDFBox.dll будет осуществляться внутри 1С через .Net Bridge.

Загрузка всех необходимых сборок:

net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.AWT.WinForms.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Beans.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Core.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Jdbc.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Media.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Naming.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Security.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.SwingAWT.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Text.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.Util.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.OpenJDK.XML.API.dll");
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.Runtime.dll");

net.LoadAssemblyFrom(ПутьКСборкам + "pdfbox.dll");

Открыть файл Pdf:

pdf = net.CallStatic("org.apache.pdfbox.pdmodel.PDDocument", "load", ПутьКФайлу);

Получить текст из Pdf:

stripper = net.New("org.apache.pdfbox.util.PDFTextStripper");
текстИзPdf = stripper.getText(pdf);

Разделить документ на одностраничные Pdf:

splitter = net.New("org.apache.pdfbox.util.Splitter");
splitter.setSplitAtPage(1);
массивДокументов = splitter.split(pdf).toArray();
Для Индекс = 0 по массивДокументов.Length - 1 цикл
    массивДокументов.GetValue(Индекс).save(ПутьКФайлу + (Индекс + 1) + ".pdf");
КонецЦикла;

Создать новый документ из нечетных страниц исходного Pdf:

страницы = pdf.getDocumentCatalog().getAllPages();
newPdf = net.New("org.apache.pdfbox.pdmodel.PDDocument");
Для Индекс = 0 по страницы.size() - 1 цикл
    Если Индекс % 2 = 1 Тогда
        Продолжить;
    КонецЕсли;
    newPdf.addPage(страницы.get(Индекс));
КонецЦикла;
newPdf.save(НовыйФайлPdf);

Нерешенная проблема

Несмотря на то, что простейшие операции отработали успешно, осталась нерешенной проблема преобразования страницы/документа в файлы изображений. Ради этой операции в первую очередь испытывался PDFBox, как замена PDF-принтерам.

ТипИзображения = net.GetStatic("java.awt.image.BufferedImage", "TYPE_INT_ARGB");
imageWriter = net.New("org.apache.pdfbox.util.PDFImageWriter");
success = imageWriter.writeImage(pdf, "png", "", 1, 3, "document-img", ТипИзображения, 96);

Вышеприведенный код приводит к некорректному выводу текста в файл изображения. Результирующий png-файл выглядит следующим образом. Текст выведен очень мелким шрифтом в левом верхнем углу картинки.

Ошибка вывода PDFBox

// //

Скачать файлы

Наименование Файл Версия Размер
Архив с внешней обработкой и библиотеками 12
.zip 14,36Mb
17.09.13
12
.zip 14,36Mb Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Евгений Пономаренко (Evgen.Ponomarenko) 17.09.13 18:50
Извиняюсь за вопрос не по теме... Как там проект Доминикана? Получается что нить? Будет ли что потестить?
2. Александр Шаров (Ta_Da) 17.09.13 19:26

Именно эта (опережая чуток "троллейбус-буханку") картинка приходит на ум, когда читаешь эту статью.

В чем была необходимость так "извращаться" (т.е. не из головы же Вы наверное эту идею взяли, а какую-то конкретную задачу решали?) и/или кому это может пригодиться в реальной жизни.
Почему нельзя было использовать обычный виртуальный ПДФ принтер, вместо связки из 1С+Elisy .Net Bridge + IKVM + Java, м?
3. Сергей Карташев (Elisy) 18.09.13 09:02
(2) Ta_Da,
Не все исследования можно относить к прикладным. Есть фундаментальные исследования, которые практического смысла на первый взгляд не несут, но на которых строятся прикладные решения.

Статья, на мой взгляд, ценна по 3м показателям:
Новизна - нет информации, как интегрировать Java и 1С,
Реализуемость - статья достигла определенных результатов,
Актуальность - 1С развивается в сторону многоплатформенности. Малозамеченной, например, осталась новость, о том, что "Опубликован программный Java-интерфейс для реализации приложений по администрированию кластера серверов 1С:Предприятия 8"

Применительно к виртуальному принтеру. Действительно, задачу можно решить через виртуальный принтер. Но большой вопрос в том, как поведет себя виртуальный принтер в облачных сервисах 1С и разрешат ли его там установить. Если удастся довести до ума текущую реализацию, виртуальных принтеров не понадобится.
4. Александр Шаров (Ta_Da) 18.09.13 09:49
(3) Elisy,
Не все исследования можно относить к прикладным. Есть фундаментальные исследования, которые практического смысла на первый взгляд не несут, но на которых строятся прикладные решения.

Что-то вроде Шнобелевской премии ("... сначала заставляет улыбнуться, а потом - задуматься") ?
Просто когда я вижу Ваши изыскания на тему 1С+.Net то я их в общем-то понять могу (хотя у меня и возникает большой вопрос по реальной применимости этой связки и существованию специалистов, которые будут ей заниматься), но "1С + Java через .Net" - это что-то за гранью моего понимания.

Но большой вопрос в том, как поведет себя виртуальный принтер в облачных сервисах 1С и разрешат ли его там установить.

Виртуальный принтер, как и любой другой принтер, устанавливается на компьютере клиента. Облачный 1С или не облачный значения не имеет как бы. И если уж заводить разговор о "а разрешат ли", с большей вероятностью на облачном сервисе разрешат установить виртуальный принтер (у той же MS есть родной виртуальный принтер, который впрочем сохраняет не в pdf а в xps формат), нежели позволят водрузит конструкцию типа вашего Bridge+Java.
5. Сергей Карташев (Elisy) 18.09.13 10:12
(4) Ta_Da,
Относитесь к статье проще. Просто имейте ввиду, что если понадобится связка 1С с Java, то одним из вариантов может быть вариант предложенный здесь. Будет ли это pdf или нет в таком контексте совершенно не важно.
У 1С большие амбиции. Интеграция 1С+.Net и 1С+Java находятся в тренде 2х стратегических направлений 1С: расширение на Запад, где .Net и Java более развитые и требуется интеграция, и развитие Fresh, который базируется на серверных технологиях, где опять же .Net и Java являются родными.
Жолтокнижниг; +1 Ответить 1
6. Ийон Тихий (cool.vlad4) 18.09.13 10:31
всякие манипуляции(разделить, соединить и прочее) с pdf в dotnet делаются через pdfsharp. рендеринг в картинку делается через интероп с нативными библиотеками - mupdf, poppler, imagemagick (у этой даже есть готовый com server в коробке). причем интеропы уже сделаны и есть в интернете. зачем нужен был для этого ikvm, непонятно. кстати для рендеринга в картинку лучше сделать обычную native ВК на плюсах. тем более, что в примерах mupdf, есть консольное приложение, где эта задача решена. собственно я так и делал.
7. Данила Елистратов (CagoBHuK) 18.09.13 10:42
(2) Ta_Da, я бы просто написал внешнюю компоненту.
8. Сергей Карташев (Elisy) 18.09.13 10:56
(6) cool.vlad4, (7) CagoBHuK,
Хорошо, наверное, тем, кто умеет писать "обычную" ВК на плюсах :)
В статье задача решена кодом 1С с возможностью отладки и просмотра значений отладчиком 1С. Это значит, что в случае ошибок или изменений не нужно лезть в ВК и перекомпилировать ВК.
9. Ийон Тихий (cool.vlad4) 18.09.13 11:09
(8) Elisy, в каком месте это код 1С?
net.LoadAssemblyFrom(ПутьКСборкам + "IKVM.AWT.WinForms.dll");
[скипнуто]
net.LoadAssemblyFrom(ПутьКСборкам + "pdfbox.dll");
pdf = net.CallStatic("org.apache.pdfbox.pdmodel.PDDocument", "load", ПутьКФайлу);

т.е. код 1С перемешанный с вызовом не 1С функций, перестает быть просто 1С кодом. я уверен, что у человека, знакомого только с 1С, в данном случае возникнут проблемы.
или вот например
splitter = net.New("org.apache.pdfbox.util.Splitter");
splitter.setSplitAtPage(1);
массивДокументов = splitter.split(pdf).toArray();
Для Индекс = 0 по массивДокументов.Length - 1 цикл
массивДокументов.GetValue(Индекс).save(ПутьКФайлу + (Индекс + 1) + ".pdf");
КонецЦикла;

ну очевидно же, что человек который это написал, видел пример или читал документацию по использованию pdfbox. т.е. одним 1С тут не обошлось. а какой тогда смысл? что в ВК написать, используя синтаксис соответствующего языка, что в 1С, используя синтаксис 1С. синтаксис это не такая уж сложная вещь, конечно (хотя плюсы это исключение;))
10. Ийон Тихий (cool.vlad4) 18.09.13 11:18
(8) Elisy, и кстати довод в пользу 1С относительно средств разработки, слабый. уж вам ли не знать, что студия на порядок круче 1С, лучше там написать код, написать код для тестов, прогнать тесты и все такое. а потом уже готовое использовать в 1С. а вот как раз отладка универсальных ВК как в статье, может вызвать проблемы.
11. Сергей Карташев (Elisy) 18.09.13 11:26
(9) cool.vlad4,
Код, написанный в конфигураторе 1С всегда останется кодом 1С со своими преимуществами:
Возможностью отладки конфигуратором
Без дополнительных инструментов разработчика (Visual Studio, Eclipse)
Преимуществами, которые дают: хранилище, сравнение/объединение и cfu - т.е. встроенные в 1С средства.

C pdfbox разбираться в любом случае. Но в случае с ВК к этим проблемам добавится знание среды разработки.
Еще, имея готовые часто используемые примеры в статье для 1С, использование сводится к Copy+Paste. А вот ВК нужно с нуля разработать.
Я не говорю, что это не возможно, а наоборот буду рад, если появится ваша ВК. Даже в таком контексте статья полезной окажется, потому что даст импульс к конкуренции.
Повторюсь - упор в статье сделан на интеграцию Java и 1С, и эта интеграция практически реализуема.
12. Данила Елистратов (CagoBHuK) 18.09.13 11:31
(8) Elisy, Я совершенно согласен с cool.vlad4. Нет смысла городить огород через 3 разных платформы для того, чтобы получить валящееся во все стороны подобие внешнего объекта, когда можно взять и написать свой.
Aleksey.Bochkov; Ta_Da; +2 Ответить 1
13. Сергей Карташев (Elisy) 18.09.13 11:34
(10) cool.vlad4,
(8) Elisy, и кстати довод в пользу 1С относительно средств разработки, слабый. уж вам ли не знать, что студия на порядок круче 1С, лучше там написать код, написать код для тестов, прогнать тесты и все такое. а потом уже готовое использовать в 1С. а вот как раз отладка универсальных ВК как в статье, может вызвать проблемы.

Спорить, что студия на порядок круче 1С по функциональности бессмысленно. Но, мы исходим из того, что 1С отведена центральная роль в нашей работе. Поэтому если что-то можно реализовать средствами только 1С, мы это делаем, не смотря на крутость Visual Stuio. Если нельзя что-то сделать или не устраивает по производительности/безопасности, то ищем другие возможности.
Не понятно о каких проблемах отладки универсальных ВК идет речь. Я предпочитаю иметь универсальную ВК вместо набора ВК, на все случаи жизни.
14. Ийон Тихий (cool.vlad4) 18.09.13 11:43
(13) Elisy,
Не понятно о каких проблемах отладки универсальных ВК идет речь. Я предпочитаю иметь универсальную ВК вместо набора ВК, на все случаи жизни.
вообще-то это был твой же аргумент. тогда мне непонятно о каких проблемах отладки обычных ВК говорил ты? ну вылезет какой-нибудь exception, в студии посмотрел stacktrace и все такое, а в 1С что мне делать? сорцы же ты не даешь? я уж молчу про статическую типизацию, и про то что в 1С из-за отсутствия оной возникает большинство глупых ошибок.
15. Сергей Карташев (Elisy) 18.09.13 11:43
(12)
Elisy, Я совершенно согласен с cool.vlad4. Нет смысла городить огород через 3 разных платформы для того, чтобы получить валящееся во все стороны подобие внешнего объекта, когда можно взять и написать свой.

Кто спорит, что более эффективные решения лучше использовать, чем менее эффективные. Но где альтернативные решения? Мы сейчас обсуждаем готовое решение с потенциально возможным. Я не говорю о виртуальном принтере, потому что подходы принципиально разные у решений.
Рациональное зерно есть в ActiveX, предложенном cool.vlad4. Но насколько это решение функциональное, не понятно.
16. Данила Елистратов (CagoBHuK) 18.09.13 11:48
(15) Elisy, во-первых, используя несколько платформ, вы катастрофически проседаете в производительности, так как начинаются кросплатформенные вызовы. COM и ActiveX - далеко не самые быстрые объекты. Их скорость - просто черепашья! Нативная внешняя компонента работает без этих недостатков. Во-вторых, альтернатива не всегда есть хорошо. Можно из СПб в Москву ехать через Владивосток. Альтернатива? Да. Хорошая альтернатива? Нет.
17. Сергей Карташев (Elisy) 18.09.13 12:55
(14) cool.vlad4,
вообще-то это был твой же аргумент. тогда мне непонятно о каких проблемах отладки обычных ВК говорил ты? ну вылезет какой-нибудь exception, в студии посмотрел stacktrace и все такое, а в 1С что мне делать? сорцы же ты не даешь? я уж молчу про статическую типизацию, и про то что в 1С из-за отсутствия оной возникает большинство глупых ошибок.

Отлаженность и доверие к универсальному продукту - это конкурентное преимущество перед узкоспециализированными ВК. Часто проблемы возникают в промышленном использовании на стороне пользователя, где недоступна студия, а "какой-нибудь exception" приводит к крэшу приложения. В таких условиях применение универсальной ВК более оправдано из-за низкой вероятности ошибки. Вероятность эту обеспечивает большее сообщество пользователей, применяющих компонент на практике.
Открытие исходников сейчас не оправдано, так как в плохом положении окажутся пользователи, приобретающие компонент. Но исходники будут сразу же открыты в случае невозможности поддерживать продукт. Такое положение вещей считаю справедливым.
Про статическую типизацию не совсем понятно высказывание. При каком использовании возникают такие ошибки? Если про преобразование всегда в int числа из 1С, хотя требуется single, то эта проблема решена в .Net Bridge.
18. Александр Шаров (Ta_Da) 18.09.13 12:59
(7) CagoBHuK, а кто спорит-то? Просто в озвученном варианте "1С в облаке" виртуальный принтер это еще более простой вариант. нежели даже внешняя компонента, не говоря уж о предложенной связке.

(5) Elisy,
У 1С большие амбиции. Интеграция 1С+.Net и 1С+Java находятся в тренде 2х стратегических направлений 1С: расширение на Запад, где .Net и Java более развитые и требуется интеграция, и развитие Fresh, который базируется на серверных технологиях, где опять же .Net и Java являются родными.

Я (не являясь не то что партнером, а даже сотрудником франчайзи) о стратегических планах судить могу конечно только со стороны, но Ваше их видение представляется мне крайне сомнительным. Исходя из того что я вижу в развитии платформы, стратегические направления 1С следующие:
1) масштабируемость: трехзвенка (в том числе и с веб-клиентом) возможность запуска на iOS/Android, улучшение производительности;
2) стандартизация разработок: БСП, рекомендации по разработке и т.п.
3) "стандартизация" разработчиков: развитая система сертификации, обилие подробных официальных книг по платформе (в сравнении с 7.7 - когда подробную специфическую информацию можно найти только на форумах типа ИС, Мисты, Кубани);

я не вижу куда здесь можно приткнуть "интеграция 1С с <Какой-то язык программирования>" и самое главное - не вижу зачем это нужно. Человек который в достаточной мере знает 1С и .Net (а в случае этой статьи еще и Java) это явно не среднестатистический 1Сник и уж тем более ситуация, когда этот человек не может написать просто ВК, а вынужден использовать подобные ухищрения, если вообще возможна, то точно не является чем-то остро необходимым.

Идея же что на западе ждут "систему 1С, к которой можно прикрутить .Net и Java и писать сразу на трех языках", представляется мне немного странной. Если продавать ВАЗы, у которых в качестве дани моде в руль встроен айпэд, то западные покупатели покрутят пальцем у виска, а не побегут их покупать. И я уверен что это понимают в 1С. На западе нужна развитая/стабильная/маштабируемая платформа, а не монстр Франкенштейна.

P.S. Не в обиду - но лично меня сильно удивляет даже тот факт, что Ваш .Net Bridge получил "1С: Совместимо".
19. Данила Елистратов (CagoBHuK) 18.09.13 13:15
(18) Ta_Da, пожалуй, подпишусь под каждым словом, кроме виртуального принтера.
20. Сергей Карташев (Elisy) 18.09.13 14:00
(16) CagoBHuK,
Elisy, во-первых, используя несколько платформ, вы катастрофически проседаете в производительности, так как начинаются кросплатформенные вызовы. COM и ActiveX - далеко не самые быстрые объекты. Их скорость - просто черепашья! Нативная внешняя компонента работает без этих недостатков. Во-вторых, альтернатива не всегда есть хорошо. Можно из СПб в Москву ехать через Владивосток. Альтернатива? Да. Хорошая альтернатива? Нет.

В случае с маршрутом СПб-Москва у нас хоть варианты озвучены - конкретика есть. Правда корректнее сравнивать поездку СПб-Москва на машине или самолете, потому что изначально задачи посетить Владивосток нет :). В случае сравнения альтернатив PDF не понятно кого с чем сравнивать. Дайте ссылку на публикацию, будем предметно говорить.
Катастрофические проседания в производительности, это конечно сильно сказано. Если есть потери, то на уровне преобразования параметров функций, так как сами функции в пределах одной платформы выполняются. Преобразование же параметров - отдельный вопрос, но во многих случаях сводится к обмену простейших типов или ссыками на простейшие типы. По сравнению с запросами к БД в 1С такие потери пренебрежительно малы.
22. Сергей Карташев (Elisy) 18.09.13 14:52
(18) Ta_Da,
CagoBHuK, а кто спорит-то? Просто в озвученном варианте "1С в облаке" виртуальный принтер это еще более простой вариант. нежели даже внешняя компонента, не говоря уж о предложенной связке.

По поводу облака, стараюсь очень осторожно высказываться. Но то, что это более простое решение, не все так однозначно. Потому что принтер на стороне сервера - это ограниченный ресурс. И непонятно, как он будет справляться с конкурентными запросами нескольких пользователей.

Я (не являясь не то что партнером, а даже сотрудником франчайзи) о стратегических планах судить могу конечно только со стороны, но Ваше их видение представляется мне крайне сомнительным. Исходя из того что я вижу в развитии платформы, стратегические направления 1С следующие:
1) масштабируемость: трехзвенка (в том числе и с веб-клиентом) возможность запуска на iOS/Android, улучшение производительности;
2) стандартизация разработок: БСП, рекомендации по разработке и т.п.
3) "стандартизация" разработчиков: развитая система сертификации, обилие подробных официальных книг по платформе (в сравнении с 7.7 - когда подробную специфическую информацию можно найти только на форумах типа ИС, Мисты, Кубани);

Прогнозы - дело неблагодарное. Но я останусь при своем мнении вот по какой причине. Ни один из ваших пунктов не приводит к увеличению прибыли компании 1С. В том или ином виде эти пункты уже выполнены. А развитие на Запад и облачные технологии позволяют расширить рынок сбыта и дать стабильный доход на постоянной основе. Прибыльность определяет действия таких коммерческих компаний, как 1С.

P.S. Не в обиду - но лично меня сильно удивляет даже тот факт, что Ваш .Net Bridge получил "1С: Совместимо".

А это еще почему? :) Никаких обид - каждый имеет право на свое мнение. Просто, интересно.
23. Александр Шаров (Ta_Da) 18.09.13 15:27
(22) Elisy,
Потому что принтер на стороне сервера - это ограниченный ресурс

так на стороне клиента же, а не на сервере.

Ни один из ваших пунктов не приводит к увеличению прибыли компании 1С. В том или ином виде эти пункты уже выполнены. А развитие на Запад и облачные технологии позволяют расширить рынок сбыта и дать стабильный доход на постоянной основе. Прибыльность определяет действия таких коммерческих компаний, как 1С.

К увеличению прибыли компании 1С приведет переход крупных клиентов на платформу 1С. Если система А масштабируется на N тысяч пользователей, а система Б - нет, то крупный бизнес на нее не перейдет (ну это если считать, что систему учетную выбирают исходя из функционала, а не "я вчера с мужиками в бане пил, у них у всех стоит система "B". "В" - это круто, не буду лохом и тоже ее себе куплю"). Будут крупные клиенты - будет прибыль. SAP не так давно больше 50% всех денег потраченных на автоматизацию в РФ забирал, при на порядки уступающем 1С количестве внедрений.

Аналогично с остальными пунктами: стандартизованное решение с которым может разобраться любой среднестатистический разработчик, без необходимости переписывать все с нуля и без попыток понять почему предыдущий разработчик реализовал хранение курсов валют во внешней базе MySQL, а не на регистре сведений, позволяет серьезно уменьшить стоимость поддержки и риски, что фирма завтра не станет заложником одного программиста/фирмы-франчайзи.

А это еще почему? :) Никаких обид - каждый имеет право на свое мнение. Просто, интересно.

Не знаю. При всем интересе к Вашей разработке, я не считаю что ее можно считать "1С:Совместимо". Уж по крайней мере не больше чем разнообразные КЗК/Gcomp/FormEx/1Cpp и т.п. Особенно в свете Ваших статей, в которых в том числе приводилась в качестве преимущества возможность прямого обращения к БД 1С. Возможно, я просто не верно понимаю критерии "1С:Совместимости".
24. Сергей Карташев (Elisy) 19.09.13 09:13
(21) CagoBHuK,

По Гуглу 736 тысяч результатов без даже близкого сходства с обсуждаемой нами темой. Это несерьезно.
Перейдем к http://www.quickpdflibrary.com/products/quickpdf/index.php
Я правильно понимаю, что под альтернативой вы понимаете Native API-приложение, написанное на VC++, задачей которого является передача параметров в API quickpdflibrary, и передача результата обратно в 1С? Или речь идет об использовании quickpdflibrary в виде ActiveX?
25. Сергей Карташев (Elisy) 19.09.13 09:25
(23) Ta_Da,
Виртуальный принтер на стороне клиента - я об этом даже не подумал. Потому что надежнее иметь один источник PDF на стороне сервера, чем 300-1000 на стороне клиентов, которые нужно еще и поддерживать, консультировать.

По поводу подсчета чужой прибыли - прибыли 1С, думаю, обсуждение будет контрпродуктивно. Просто останемся каждый при своем мнении.

Не знаю. При всем интересе к Вашей разработке, я не считаю что ее можно считать "1С:Совместимо". Уж по крайней мере не больше чем разнообразные КЗК/Gcomp/FormEx/1Cpp и т.п. Особенно в свете Ваших статей, в которых в том числе приводилась в качестве преимущества возможность прямого обращения к БД 1С. Возможно, я просто не верно понимаю критерии "1С:Совместимости".

Вас ввела в заблуждение приставка Elisy. Продукты на самом деле разные. 1С:Совместимо получил продукт Elisy .Net Bridge. В этом продукте нет ничего противозаконного - он является мостом между 1С и .Net Bridge, выполнен в строгом соответствии по технологии ВК. Но кроме него есть другие продукты, статус которых вряд ли удастся подтвердить: Elisy LinqTo1C и т.д.
Кстати, благодаря статусу .Net Bridge сейчас теоретически возможно любым библиотекам .Net получить статус 1С-совместимо, потому что они все доступны в платформе 1С через него.
26. Данила Елистратов (CagoBHuK) 19.09.13 09:26
(24) Elisy, как альтернативу используйте в качестве ActiveX или COM. Я привел этот объект просто в пример. Найдите любой и используйте таким же образом. Вариантов использования буквально два:
  • Внешняя компонента на NativeAPI
  • Использование любого стороннего компонента в COM/ActiveX
27. Евгений Стоянов (quick) 12.05.14 17:20
Все эти игры с .NET прекрасны пока разработка не пошла в массы, а там у клиентов... каких только глюков не на ловишь. То фреймворк не ставится, то права доступа не такие, то обновления поломались..
28. Сергей Карташев (Elisy) 13.05.14 07:08
(27) quick,
Если сравнивать .Net и 1С, то .Net на уровень выше по надежности из-за более массового распространения в мире. У .Net массовости и продуктов, основанных на нем, тоже в мире выше намного. Поэтому откуда такие сомнения - не ясно. Можно как-то аргументировать такие заявления?
29. Александр Шаров (Ta_Da) 13.05.14 11:19
(28) Elisy, я не знаю что имел в виду quick, но я вижу проблемы в следующем:
Bridge (судя по информации у Вас на сайте) требует для нормальной работы .Net 4, который не ставится на Windows XP без сервиспаков. Оно как бы понятно, что Windows XP уже с поддержки снята, но в реальной жизни фирмы ей будут пользоваться до полного физического устаревания компьютеров, на которых они установлены. Тем более, если были куплены лицензии. И вот тут возникает проблема. Это если говорить про мелкий/средний бизнес.
С крупным, возможно, такой проблемы не будет, с другой стороны может возникнуть проблема с админами/безопасниками, которые не факт что будут рады установке на сервер кучи сторонних фреймворков, только ради того, чтобы менеджер мог распечатать что-то в ПДФ (я понимаю, что это был просто пример, чтобы продемонстрировать техническую возможность, но ...).
+ есть еще вариант с 1С на линукс-сервере, там пляски с бубном вокруг .Net (пусть Mono) могут достигнуть космических масштабов.

В общем-то мое (и похоже не только мое) отношение к разработке было бы совсем другим, если бы Вы предложили какой-то вариант использования, который не решается с помощью ВК или хотя бы без Java. Встретили по одежке, так сказать. При этом чисто технически - решение вызывает интерес.
30. Сергей Карташев (Elisy) 13.05.14 13:41
(29)
Я, если честно, данную разработку всерьез не рассматриваю с претензией на практическую ценность. Разработка больше интересна сделанным выводом, что связка 1С и Java возможна. До этого момента таких связок я не видел.
Я уверен, что существуют сборки для .Net, решающие эти же операции, что позволяет отказаться конкретно в данной задаче от Java.
По поводу XP. Насколько знаю, .Net Framework 4 поддерживает XP. Именно поэтому Bridge не компилируется для следующего .Net 4.5, хотя теоретически поддерживает.
На Linux Bridge не работает, потому что основан на COM, но и аналога я не знаю.
31. Александр Шаров (Ta_Da) 13.05.14 16:09
(30) Elisy, .net 4 работает только на Windows XP Service Pack 3 и 2003 sp2. По своему опыту - в 90% небольших фирм, стоит xpsp2 и 2003 без сервиспаков. Т.е. как настроил приходящий эникейщик лет N-дцать назад - так и работает. Это не аргумент против Bridge, просто мысли вслух =)
32. Евгений Стоянов (quick) 24.07.14 17:56
(30) Elisy, Пытался недавно интегрировать python и и пришел к выводу что самый лучший способ это SOAP. Тогда и python можно вынести на любой сервер и для 1С не надо придумывать никаких компонент, прекрасно работают встроенные объекты. Быстро и справляются с огромными данными за один запрос. Вот рабочий пример такой связки сделанный на этом принципе http://infostart.ru/public/270582/
И как плюс никакой разницы linux windows, все работает на единой кодовой базе. Ну и плюс с помощью сессий можно решить на стороне питона вопрос с вызовами методов между разными процессами и серверами 1С.
33. Сергей Карташев (Elisy) 25.07.14 06:27
(32) quick,
Связка с 1С через SOAP действительно хороша. Есть одно ограничение - в облачных fresh-решениях, насколько знаю, нельзя публиковать веб-сервисы. В этом случае может больше подойти решение Business Connector
http://infostart.ru/public/153679/
http://www.1csoftware.com/connector/ru-ru
где доступ к 1С осуществляется через веб-интерфейс 1С и доступны экспортные серверные функции
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа