Интеграция 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~1Javajre6
Команда преобразования сборки имеет следующий вид:
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-файл выглядит следующим образом. Текст выведен очень мелким шрифтом в левом верхнем углу картинки.
//
//
Извиняюсь за вопрос не по теме… Как там проект Доминикана? Получается что нить? Будет ли что потестить?
Именно эта (опережая чуток «троллейбус-буханку») картинка приходит на ум, когда читаешь эту статью.
В чем была необходимость так «извращаться» (т.е. не из головы же Вы наверное эту идею взяли, а какую-то конкретную задачу решали?) и/или кому это может пригодиться в реальной жизни.
Почему нельзя было использовать обычный виртуальный ПДФ принтер, вместо связки из 1С+Elisy .Net Bridge + IKVM + Java, м?
(2) Ta_Da,
Не все исследования можно относить к прикладным. Есть фундаментальные исследования, которые практического смысла на первый взгляд не несут, но на которых строятся прикладные решения.
Статья, на мой взгляд, ценна по 3м показателям:
Новизна — нет информации, как интегрировать Java и 1С,
Реализуемость — статья достигла определенных результатов,
Актуальность — 1С развивается в сторону многоплатформенности. Малозамеченной, например, осталась новость, о том, что «Опубликован программный Java-интерфейс для реализации приложений по администрированию кластера серверов 1С:Предприятия 8»
Применительно к виртуальному принтеру. Действительно, задачу можно решить через виртуальный принтер. Но большой вопрос в том, как поведет себя виртуальный принтер в облачных сервисах 1С и разрешат ли его там установить. Если удастся довести до ума текущую реализацию, виртуальных принтеров не понадобится.
(3)
Что-то вроде Шнобелевской премии («… сначала заставляет улыбнуться, а потом — задуматься») ?
Просто когда я вижу Ваши изыскания на тему 1С+.Net то я их в общем-то понять могу (хотя у меня и возникает большой вопрос по реальной применимости этой связки и существованию специалистов, которые будут ей заниматься), но «1С + Java через .Net» — это что-то за гранью моего понимания.
Виртуальный принтер, как и любой другой принтер, устанавливается на компьютере клиента. Облачный 1С или не облачный значения не имеет как бы. И если уж заводить разговор о «а разрешат ли», с большей вероятностью на облачном сервисе разрешат установить виртуальный принтер (у той же MS есть родной виртуальный принтер, который впрочем сохраняет не в pdf а в xps формат), нежели позволят водрузит конструкцию типа вашего Bridge+Java.
(4) Ta_Da,
Относитесь к статье проще. Просто имейте ввиду, что если понадобится связка 1С с Java, то одним из вариантов может быть вариант предложенный здесь. Будет ли это pdf или нет в таком контексте совершенно не важно.
У 1С большие амбиции. Интеграция 1С+.Net и 1С+Java находятся в тренде 2х стратегических направлений 1С: расширение на Запад, где .Net и Java более развитые и требуется интеграция, и развитие Fresh, который базируется на серверных технологиях, где опять же .Net и Java являются родными.
всякие манипуляции(разделить, соединить и прочее) с pdf в dotnet делаются через pdfsharp. рендеринг в картинку делается через интероп с нативными библиотеками — mupdf, poppler, imagemagick (у этой даже есть готовый com server в коробке). причем интеропы уже сделаны и есть в интернете. зачем нужен был для этого ikvm, непонятно. кстати для рендеринга в картинку лучше сделать обычную native ВК на плюсах. тем более, что в примерах mupdf, есть консольное приложение, где эта задача решена. собственно я так и делал.
(2) Ta_Da, я бы просто написал внешнюю компоненту.
(6) cool.vlad4, (7) CagoBHuK,
Хорошо, наверное, тем, кто умеет писать «обычную» ВК на плюсах 🙂
В статье задача решена кодом 1С с возможностью отладки и просмотра значений отладчиком 1С. Это значит, что в случае ошибок или изменений не нужно лезть в ВК и перекомпилировать ВК.
(8) в каком месте это код 1С?
[скипнуто]
net.LoadAssemblyFrom(ПутьКСборкам + «pdfbox.dll»);
pdf = net.CallStatic(«org.apache.pdfbox.pdmodel.PDDocument», «load», ПутьКФайлу);
т.е. код 1С перемешанный с вызовом не 1С функций, перестает быть просто 1С кодом. я уверен, что у человека, знакомого только с 1С, в данном случае возникнут проблемы.
или вот например
splitter.setSplitAtPage(1);
массивДокументов = splitter.split(pdf).toArray();
Для Индекс = 0 по массивДокументов.Length — 1 цикл
массивДокументов.GetValue(Индекс).save(ПутьКФайлу + (Индекс + 1) + «.pdf»);
КонецЦикла;
ну очевидно же, что человек который это написал, видел пример или читал документацию по использованию pdfbox. т.е. одним 1С тут не обошлось. а какой тогда смысл? что в ВК написать, используя синтаксис соответствующего языка, что в 1С, используя синтаксис 1С. синтаксис это не такая уж сложная вещь, конечно (хотя плюсы это исключение;))
(8) и кстати довод в пользу 1С относительно средств разработки, слабый. уж вам ли не знать, что студия на порядок круче 1С, лучше там написать код, написать код для тестов, прогнать тесты и все такое. а потом уже готовое использовать в 1С. а вот как раз отладка универсальных ВК как в статье, может вызвать проблемы.
(9) cool.vlad4,
Код, написанный в конфигураторе 1С всегда останется кодом 1С со своими преимуществами:
Возможностью отладки конфигуратором
Без дополнительных инструментов разработчика (Visual Studio, Eclipse)
Преимуществами, которые дают: хранилище, сравнение/объединение и cfu — т.е. встроенные в 1С средства.
C pdfbox разбираться в любом случае. Но в случае с ВК к этим проблемам добавится знание среды разработки.
Еще, имея готовые часто используемые примеры в статье для 1С, использование сводится к Copy+Paste. А вот ВК нужно с нуля разработать.
Я не говорю, что это не возможно, а наоборот буду рад, если появится ваша ВК. Даже в таком контексте статья полезной окажется, потому что даст импульс к конкуренции.
Повторюсь — упор в статье сделан на интеграцию Java и 1С, и эта интеграция практически реализуема.
(8) Я совершенно согласен с cool.vlad4. Нет смысла городить огород через 3 разных платформы для того, чтобы получить валящееся во все стороны подобие внешнего объекта, когда можно взять и написать свой.
(10) cool.vlad4,
Спорить, что студия на порядок круче 1С по функциональности бессмысленно. Но, мы исходим из того, что 1С отведена центральная роль в нашей работе. Поэтому если что-то можно реализовать средствами только 1С, мы это делаем, не смотря на крутость Visual Stuio. Если нельзя что-то сделать или не устраивает по производительности/безопасности, то ищем другие возможности.
Не понятно о каких проблемах отладки универсальных ВК идет речь. Я предпочитаю иметь универсальную ВК вместо набора ВК, на все случаи жизни.
(13)
вообще-то это был твой же аргумент. тогда мне непонятно о каких проблемах отладки обычных ВК говорил ты? ну вылезет какой-нибудь exception, в студии посмотрел stacktrace и все такое, а в 1С что мне делать? сорцы же ты не даешь? я уж молчу про статическую типизацию, и про то что в 1С из-за отсутствия оной возникает большинство глупых ошибок.
(12)
Кто спорит, что более эффективные решения лучше использовать, чем менее эффективные. Но где альтернативные решения? Мы сейчас обсуждаем готовое решение с потенциально возможным. Я не говорю о виртуальном принтере, потому что подходы принципиально разные у решений.
Рациональное зерно есть в ActiveX, предложенном cool.vlad4. Но насколько это решение функциональное, не понятно.
(15) во-первых, используя несколько платформ, вы катастрофически проседаете в производительности, так как начинаются кросплатформенные вызовы. COM и ActiveX — далеко не самые быстрые объекты. Их скорость — просто черепашья! Нативная внешняя компонента работает без этих недостатков. Во-вторых, альтернатива не всегда есть хорошо. Можно из СПб в Москву ехать через Владивосток. Альтернатива? Да. Хорошая альтернатива? Нет.
(14) cool.vlad4,
Отлаженность и доверие к универсальному продукту — это конкурентное преимущество перед узкоспециализированными ВК. Часто проблемы возникают в промышленном использовании на стороне пользователя, где недоступна студия, а «какой-нибудь exception» приводит к крэшу приложения. В таких условиях применение универсальной ВК более оправдано из-за низкой вероятности ошибки. Вероятность эту обеспечивает большее сообщество пользователей, применяющих компонент на практике.
Открытие исходников сейчас не оправдано, так как в плохом положении окажутся пользователи, приобретающие компонент. Но исходники будут сразу же открыты в случае невозможности поддерживать продукт. Такое положение вещей считаю справедливым.
Про статическую типизацию не совсем понятно высказывание. При каком использовании возникают такие ошибки? Если про преобразование всегда в int числа из 1С, хотя требуется single, то эта проблема решена в .Net Bridge.
(7) CagoBHuK, а кто спорит-то? Просто в озвученном варианте «1С в облаке» виртуальный принтер это еще более простой вариант. нежели даже внешняя компонента, не говоря уж о предложенной связке.
(5)
Я (не являясь не то что партнером, а даже сотрудником франчайзи) о стратегических планах судить могу конечно только со стороны, но Ваше их видение представляется мне крайне сомнительным. Исходя из того что я вижу в развитии платформы, стратегические направления 1С следующие:
1) масштабируемость: трехзвенка (в том числе и с веб-клиентом) возможность запуска на iOS/Android, улучшение производительности;
2) стандартизация разработок: БСП, рекомендации по разработке и т.п.
3) «стандартизация» разработчиков: развитая система сертификации, обилие подробных официальных книг по платформе (в сравнении с 7.7 — когда подробную специфическую информацию можно найти только на форумах типа ИС, Мисты, Кубани);
я не вижу куда здесь можно приткнуть «интеграция 1С с <Какой-то язык программирования>» и самое главное — не вижу зачем это нужно. Человек который в достаточной мере знает 1С и .Net (а в случае этой статьи еще и Java) это явно не среднестатистический 1Сник и уж тем более ситуация, когда этот человек не может написать просто ВК, а вынужден использовать подобные ухищрения, если вообще возможна, то точно не является чем-то остро необходимым.
Идея же что на западе ждут «систему 1С, к которой можно прикрутить .Net и Java и писать сразу на трех языках», представляется мне немного странной. Если продавать ВАЗы, у которых в качестве дани моде в руль встроен айпэд, то западные покупатели покрутят пальцем у виска, а не побегут их покупать. И я уверен что это понимают в 1С. На западе нужна развитая/стабильная/маштабируемая платформа, а не монстр Франкенштейна.
P.S. Не в обиду — но лично меня сильно удивляет даже тот факт, что Ваш .Net Bridge получил «1С: Совместимо».
(18) Ta_Da, пожалуй, подпишусь под каждым словом, кроме виртуального принтера.
(16) CagoBHuK,
В случае с маршрутом СПб-Москва у нас хоть варианты озвучены — конкретика есть. Правда корректнее сравнивать поездку СПб-Москва на машине или самолете, потому что изначально задачи посетить Владивосток нет :). В случае сравнения альтернатив PDF не понятно кого с чем сравнивать. Дайте ссылку на публикацию, будем предметно говорить.
Катастрофические проседания в производительности, это конечно сильно сказано. Если есть потери, то на уровне преобразования параметров функций, так как сами функции в пределах одной платформы выполняются. Преобразование же параметров — отдельный вопрос, но во многих случаях сводится к обмену простейших типов или ссыками на простейшие типы. По сравнению с запросами к БД в 1С такие потери пренебрежительно малы.
(20) ммммм…..https://www.google.ru/search?hl=ru&q=1%D1%81+%D1%87%D1%82%D0%B5%D0%BD%D0%B8%D0%B5+pdf&btn G=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr= Так? Навскидку даже вот: http://www.quickpdflibrary.com/products/quickpdf/index.php
(18) Ta_Da,
По поводу облака, стараюсь очень осторожно высказываться. Но то, что это более простое решение, не все так однозначно. Потому что принтер на стороне сервера — это ограниченный ресурс. И непонятно, как он будет справляться с конкурентными запросами нескольких пользователей.
1) масштабируемость: трехзвенка (в том числе и с веб-клиентом) возможность запуска на iOS/Android, улучшение производительности;
2) стандартизация разработок: БСП, рекомендации по разработке и т.п.
3) «стандартизация» разработчиков: развитая система сертификации, обилие подробных официальных книг по платформе (в сравнении с 7.7 — когда подробную специфическую информацию можно найти только на форумах типа ИС, Мисты, Кубани);
Прогнозы — дело неблагодарное. Но я останусь при своем мнении вот по какой причине. Ни один из ваших пунктов не приводит к увеличению прибыли компании 1С. В том или ином виде эти пункты уже выполнены. А развитие на Запад и облачные технологии позволяют расширить рынок сбыта и дать стабильный доход на постоянной основе. Прибыльность определяет действия таких коммерческих компаний, как 1С.
А это еще почему? 🙂 Никаких обид — каждый имеет право на свое мнение. Просто, интересно.
(22)
так на стороне клиента же, а не на сервере.
К увеличению прибыли компании 1С приведет переход крупных клиентов на платформу 1С. Если система А масштабируется на N тысяч пользователей, а система Б — нет, то крупный бизнес на нее не перейдет (ну это если считать, что систему учетную выбирают исходя из функционала, а не «я вчера с мужиками в бане пил, у них у всех стоит система «B». «В» — это круто, не буду лохом и тоже ее себе куплю»). Будут крупные клиенты — будет прибыль. SAP не так давно больше 50% всех денег потраченных на автоматизацию в РФ забирал, при на порядки уступающем 1С количестве внедрений.
Аналогично с остальными пунктами: стандартизованное решение с которым может разобраться любой среднестатистический разработчик, без необходимости переписывать все с нуля и без попыток понять почему предыдущий разработчик реализовал хранение курсов валют во внешней базе MySQL, а не на регистре сведений, позволяет серьезно уменьшить стоимость поддержки и риски, что фирма завтра не станет заложником одного программиста/фирмы-франчайзи.
Не знаю. При всем интересе к Вашей разработке, я не считаю что ее можно считать «1С:Совместимо». Уж по крайней мере не больше чем разнообразные КЗК/Gcomp/FormEx/1Cpp и т.п. Особенно в свете Ваших статей, в которых в том числе приводилась в качестве преимущества возможность прямого обращения к БД 1С. Возможно, я просто не верно понимаю критерии «1С:Совместимости».
(21) CagoBHuK,
По Гуглу 736 тысяч результатов без даже близкого сходства с обсуждаемой нами темой. Это несерьезно.
http://www.quickpdflibrary.com/products/quickpdf/index.php
Перейдем к
Я правильно понимаю, что под альтернативой вы понимаете Native API-приложение, написанное на VC++, задачей которого является передача параметров в API quickpdflibrary, и передача результата обратно в 1С? Или речь идет об использовании quickpdflibrary в виде ActiveX?
(23) Ta_Da,
Виртуальный принтер на стороне клиента — я об этом даже не подумал. Потому что надежнее иметь один источник PDF на стороне сервера, чем 300-1000 на стороне клиентов, которые нужно еще и поддерживать, консультировать.
По поводу подсчета чужой прибыли — прибыли 1С, думаю, обсуждение будет контрпродуктивно. Просто останемся каждый при своем мнении.
Вас ввела в заблуждение приставка Elisy. Продукты на самом деле разные. 1С:Совместимо получил продукт Elisy .Net Bridge. В этом продукте нет ничего противозаконного — он является мостом между 1С и .Net Bridge, выполнен в строгом соответствии по технологии ВК. Но кроме него есть другие продукты, статус которых вряд ли удастся подтвердить: Elisy LinqTo1C и т.д.
Кстати, благодаря статусу .Net Bridge сейчас теоретически возможно любым библиотекам .Net получить статус 1С-совместимо, потому что они все доступны в платформе 1С через него.
(24) как альтернативу используйте в качестве ActiveX или COM. Я привел этот объект просто в пример. Найдите любой и используйте таким же образом. Вариантов использования буквально два:
Все эти игры с .NET прекрасны пока разработка не пошла в массы, а там у клиентов… каких только глюков не на ловишь. То фреймворк не ставится, то права доступа не такие, то обновления поломались..
(27) quick,
Если сравнивать .Net и 1С, то .Net на уровень выше по надежности из-за более массового распространения в мире. У .Net массовости и продуктов, основанных на нем, тоже в мире выше намного. Поэтому откуда такие сомнения — не ясно. Можно как-то аргументировать такие заявления?
(28) я не знаю что имел в виду quick, но я вижу проблемы в следующем:
Bridge (судя по информации у Вас на сайте) требует для нормальной работы .Net 4, который не ставится на Windows XP без сервиспаков. Оно как бы понятно, что Windows XP уже с поддержки снята, но в реальной жизни фирмы ей будут пользоваться до полного физического устаревания компьютеров, на которых они установлены. Тем более, если были куплены лицензии. И вот тут возникает проблема. Это если говорить про мелкий/средний бизнес.
С крупным, возможно, такой проблемы не будет, с другой стороны может возникнуть проблема с админами/безопасниками, которые не факт что будут рады установке на сервер кучи сторонних фреймворков, только ради того, чтобы менеджер мог распечатать что-то в ПДФ (я понимаю, что это был просто пример, чтобы продемонстрировать техническую возможность, но …).
+ есть еще вариант с 1С на линукс-сервере, там пляски с бубном вокруг .Net (пусть Mono) могут достигнуть космических масштабов.
В общем-то мое (и похоже не только мое) отношение к разработке было бы совсем другим, если бы Вы предложили какой-то вариант использования, который не решается с помощью ВК или хотя бы без Java. Встретили по одежке, так сказать. При этом чисто технически — решение вызывает интерес.
(29)
Я, если честно, данную разработку всерьез не рассматриваю с претензией на практическую ценность. Разработка больше интересна сделанным выводом, что связка 1С и Java возможна. До этого момента таких связок я не видел.
Я уверен, что существуют сборки для .Net, решающие эти же операции, что позволяет отказаться конкретно в данной задаче от Java.
По поводу XP. Насколько знаю, .Net Framework 4 поддерживает XP. Именно поэтому Bridge не компилируется для следующего .Net 4.5, хотя теоретически поддерживает.
На Linux Bridge не работает, потому что основан на COM, но и аналога я не знаю.
(30) .net 4 работает только на Windows XP Service Pack 3 и 2003 sp2. По своему опыту — в 90% небольших фирм, стоит xpsp2 и 2003 без сервиспаков. Т.е. как настроил приходящий эникейщик лет N-дцать назад — так и работает. Это не аргумент против Bridge, просто мысли вслух =)
(30) Пытался недавно интегрировать python и 1С и пришел к выводу что самый лучший способ это SOAP. Тогда и python можно вынести на любой сервер и для 1С не надо придумывать никаких компонент, прекрасно работают встроенные объекты. Быстро и справляются с огромными данными за один запрос. Вот рабочий пример такой связки сделанный на этом принципеhttp://infostart.ru/public/270582/
И как плюс никакой разницы linux windows, все работает на единой кодовой базе. Ну и плюс с помощью сессий можно решить на стороне питона вопрос с вызовами методов между разными процессами и серверами 1С.
(32) quick,
http://infostart.ru/public/153679/
http://www.1csoftware.com/connector/ru-ru
Связка с 1С через SOAP действительно хороша. Есть одно ограничение — в облачных fresh-решениях, насколько знаю, нельзя публиковать веб-сервисы. В этом случае может больше подойти решение Business Connector
где доступ к 1С осуществляется через веб-интерфейс 1С и доступны экспортные серверные функции
Не получилось подключить Net Bridge. У меня в системе стоит 6.х версия. Есть к нему пример подключения?
Тема интересная, подключать Java. А Net Bridge рисовать умеет.
Я так понимаю, тема устарела и данный код не работает.
(34) Смысл подключения не подключение к Java непосредственно, а перевод Java-библиотек под .Net Framework и подключение через Net Bridge к конвертированным библиотекам.
скачал,
pdfbox.dll сгенерировал на Win7 Java 1.8 через pdfbox-app-1.8.16
НО:
Тип не определен (AddIn.ElisyNetBridge4)
AddIn = New(«AddIn.ElisyNetBridge4»);
(36)https://infostart.ru/bitrix/components/infostart/forum.interface/show_file.php?fid=386119&action=download
нашел через
https://forum.infostart.ru/forum9/topic105353/
Все получилось, прочитал банковскую pdf выписку для обработки.
(38) откровенно говря, кроме этого случая мне не приходилось использовать Java
Большинство библиотек удается найти на C#. Многие специально были портированы с Java. Такой способ более надежный.
(39) Интересуюсь Java решениями, так как стыкую 1С с Андроид приложением самописным по основной работе. Думаю там тоже пригодится, пока обкатал на мелкой задаче. Но странно, 2019 год, а 1С читает pdf только чеша левой ногой за правым ухом. Или я чето недогуглил?