Как можно «навязать» использование 1С? Приходят и говорят: «Используй 1С, а не то изуродуем»? Насколько я знаю, SAP и Dynamics представлены на рынке, но занимают весьма скромную долю. Или «навязывние» имеется в виду предложение более дешевой, легче конфигурированной и более приспособленной к российским законам системы, что отказаться от ипсользования невозможно? Обслуживание тоже очень доступное — в каждом городе минимум по несколько 1С-партнеров. В таком случае мне, как разработчику, тоже навязали 1С, предложив оплату труда в 2 раза выше, чем зарабатывал на C++/C#. Везде бы было такое навязывание.
Хотел вас спросить еще об одном моменте. В статье используется класс System.Speech.Synthesis.SpeechSynthesizer, стандартно входящий в .Net Framework.
Но Microsoft предлагает отдельные дистрибутивы: Microsoft Speech Platform Runtime 11 и Microsoft Speech Platform — Server Runtime.
Microsoft Speech Platform Runtime 11 предлагает отдельную сборку, отличающуюся пространством имен и голоса, которые после установки не видны из стандартного класса .Net Framework.
Голоса Microsoft Speech Platform — Server Runtime идут отдельными дистрибутивами и также не видны из стандартного класса .Net Framework после установки.
Исходя из этого вопросы: чем отличаются отдельные дистрибутивы Microsoft от классов, включенных в .Net framework 3.0 и почему голоса несовместимы между собой? В реестре голоса от Speech Platform создают отдельные ветки, не входящие в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech\Voices\Tokens<code>
Спасибо за один из самых ценных комментариев. Установил RHVoice и в конце статьи привел образцы звучания для 3х голосов. Действительно RHVoice очень хорошо показал себя.
Особенностью RHVoice является произношение слов, написанных латинскими буквами на немецкий манер (например, Skype как «скипе»). Поэтому в текстовой строке пришлось заменить «Skype» на «скайп».
1С — это инструмент. Все зависит от задач. Разработать интернет-магазин без доп.средств невозможно. А разработать учет на складе или доработать бухгалтерию на отдельно взятом предприятии очень даже удобно. Где-то цифра была об 1 миллионе пользователей 1С. Это внушительная цифра. Значит очень многие находят ее удобной.
Для создания бухгалтерских и приложений по учету быстро и удобно. Для дополнительного функционала подключаю .Net framework, как в данном случае. Удобна масштабируемость от однопользовательской поставки до варианта клиент-сервер. Удобна кроссплатформенность: написанное на 1С с большой вероятностью будет работать на Windows и в новой версии на Linux. Также удобна раскрученность бренда 1С, что позволяет быстрее продать свои разработки: ведь конечная цель любых разработок, чтобы ими пользовались, а не чтобы было удобно разрабатывать.
Неудобно отношение 1С к своим разработчикам: компания 1С делает только то, что ей выгодно. При таком подходе система нестройная, развивается в непонятном направлении. А разработчики под 1С чувствуют себя как бедные родственники.
Действительно нет ООП, что, на мой взгляд, приводит к избыточности в коде — одни и те же куски кода, например, проходят через все документы.
1) 1С публикуется через веб-сервер Apache/IIS в 2х режимах: веб-сервисы (SOAP) и веб-клиент 8.2. Это негибко. Кроме этих протоколов есть другие популярные, например, JSON.
4) Как вы себе представляете вычисление абсолютных цифр? 1С выстроит все параллельные запросы в последовательное выполнение. Вероятность завершения по таймауту будет высокой.
При организации кэша на стороне .Net часть запросов пойдет без участия 1С в многопоточном режиме, что уменьшит вероятность завершения по таймауту.
На сколько выше или ниже в абсолютных цифрах — это тема отдельного исследования. Для данного метода достаточно знать, что лучше однопоточного HttpListener'а может быть многопоточный (благо .Net это позволяет). И желательно применение кэша на стороне .Net.
1. Вспомогательный функционал, вынесенный в .Net будет многопоточным и эффективным. Например, кэширование ответов на стороне .Net. По поводу веб-сервисов замеров у меня нет, если есть замер производительности, прошу поделиться. Мои личные наблюдения относительно 1С, опубликованной через веб, говорят о том, что там нет многопоточности, хотя, казалось бы, должна быть. Наверняка есть особенности и в веб-сервисах.
2. Полная подконтрольность нужна в некоторых задачах, вот реальный вопрос от пользователей: «Реализована информационная система на базе платформы „1С: Предприятие 8.2“, в системе создан Web-Сервис, на который приходят запросы с необходимой информацией в теге header. Платформа „1С: Предприятие 8.2“ не позволяет считывать информацию в теге header.»
3. В случае с 1С протокол ограничен SOAP, что не гарантирует совместимости с др.платформами. В случае с предложенной технологией протокол SOAP'ом не ограничен, выбирайте любой: JSON, REST, XML или выдумывайте свой. Стандартные случаи хорошо документированы, так как это классы .Net Framework.
4. Не обязательно через веб-сервисы. Скоро предложу на критику еще один прогрессивный метод доступа на замену веб-сервисам.
Полностью согласен, что на полноценный веб-сервер не тянет и лучше сайты делать на IIS или Apache.
Но определенные задачи веб-сервер на стороне 1С все-таки решает: например, работает с оборудованием, мониторит состояние базы.
Опыты показали, что на стороне 1С все выполняется в 1 поток. Но на стороне .Net действует многопоточность.
Потаенный смысл в следующем:
1. Само наличие веб-сервера внутри 1С
2. Полная подконтрольность — возможность управлять заголовками, кукисами и т.д.
3. Вспомогательный функционал, вынесенный в .Net будет многопоточным и эффективным. Например, кэширование ответов на стороне .Net.
4. За счет нескольких прослушивающих потоков меньшая вероятность потерять запрос.
5. Доступен сразу весь функционал .Net: можно возвращать JSON, RSS, REST, рисунки через его объекты. На рисунки можно «на лету» ставить водяные знаки.
CodeFort интересен тем, что имеет бесплатную более ограниченную версию. Бесплатная версия делает переименования и шифрование строковых констант. С обфускацией нашего кода справился продукт лучше, чем Dotfuscator, который «сломал» логику работы программы и непонятно, что с ней стало происходить — сломанный метод крэшится в Reflector'е при декомпиляции.
В Интернете прочитал, что действительно есть разделение и можно удаленно коннектиться. Для тонкого клиента будет примерно такой код:
ОбъектПодключения = "V82c.Application";
ТекCOMОбъект = Новый COMОбъект(ОбъектПодключения);
СтрокаПодключения = "ws=""http://192.168.xxx.xxx/TradeTest"";Usr=""Администратор"";Pwd=""Pass"";";
ТекCOMОбъект.Connect(СтрокаПодключения);
ТекCOMОбъект.Visible = Ложь;
Чтобы появилась запись в реестре для «V82c.Application» нужно выполнить: C:\Program Files\1cv82\8.2.xx.xx\bin\1cv8c.exe /RegServer
Соответственно для тонкого клиента весь функционал урезан.
Не совсем понятно. По КОМ я могу обратиться не только к серверу 1С, но также к 1С, работающей в файловом режиме. Я установил 8.3 и в реестре у меня появились 2 ссылки
HKEY_CLASSES_ROOT\V83.Application
HKEY_CLASSES_ROOT\V83C.Application
1) Значит ли это, что по COM я будут подключаться к неуправляемому приложению по V83.Application, а к управляемому приложению по V83C.Application? При этом функционал в V83C.Application будет намного урезанным — соответствовать функциям тонкого клиента?
2) Могу ли я установив только тонкий клиент под Windows через V83C.Application обратиться к удаленной базе, например, demo-ma.1c.ru?
Я согласен, что это один из вариантов — обходных путей. Но COM/OLE предусматривает получение данных по требованию. Например, известно много случаев, когда данные 1С берутся динамически из Asp.Net-сайтов (интернет-магазинов). Или в конвертации данных при выгрузке можно было подключиться по OLE к удаленной информационной базе и отправить данные, тем самым избежав явной операции загрузки данных. В случае с Linux отсутствие COM/OLE приведет к уменьшению функциональности.
Еще один момент остался неясным. Автор скорее всего работал с давно спроектированным приложением 1С, которое работало как неуправляемое приложение. Начиная с 8.2 появился «тонкий» клиент и будет появляться все больше конфигураций для управляемых приложений.
Есть ли вообще возможность подключения по COM к управляемому приложению, например к тому же demo-ma.1c.ru/ удаленно? И если есть, то какие ограничения накладываются на такие подключения по сравнению с подключением к «толстому» клиенту?
Видите ли — предложенный вами подход не универсальный и предполагает доработку конфигурации 1С. COM-подход же намного гибче. Например, все экспортные процедуры/функции будут автоматически доступны через COM. Т.е. в случае с COM с большей вероятностью не нужно вмешиваться в конфигурацию 1С.
Статья интересная. Но меня интересует такой момент: все больше внимания 1С уделяет Linux. И, соответственно, все больше Linux-компьютеров в будущем будут работать c 1C. И с этой точки зрения COM-доступ, описанный здесь, не будет работать. Какая альтернатива доступа к 1С извне, такая же гибкая как COM, но вместе с тем универсально подходит для Windows/Linux?
Но Microsoft предлагает отдельные дистрибутивы: Microsoft Speech Platform Runtime 11 и Microsoft Speech Platform — Server Runtime.
Microsoft Speech Platform Runtime 11 предлагает отдельную сборку, отличающуюся пространством имен и голоса, которые после установки не видны из стандартного класса .Net Framework.
Голоса Microsoft Speech Platform — Server Runtime идут отдельными дистрибутивами и также не видны из стандартного класса .Net Framework после установки.
Исходя из этого вопросы: чем отличаются отдельные дистрибутивы Microsoft от классов, включенных в .Net framework 3.0 и почему голоса несовместимы между собой? В реестре голоса от Speech Platform создают отдельные ветки, не входящие в
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Speech\Voices\Tokens<code>Особенностью RHVoice является произношение слов, написанных латинскими буквами на немецкий манер (например, Skype как «скипе»). Поэтому в текстовой строке пришлось заменить «Skype» на «скайп».
Неудобно отношение 1С к своим разработчикам: компания 1С делает только то, что ей выгодно. При таком подходе система нестройная, развивается в непонятном направлении. А разработчики под 1С чувствуют себя как бедные родственники.
Действительно нет ООП, что, на мой взгляд, приводит к избыточности в коде — одни и те же куски кода, например, проходят через все документы.
4) Как вы себе представляете вычисление абсолютных цифр? 1С выстроит все параллельные запросы в последовательное выполнение. Вероятность завершения по таймауту будет высокой.
При организации кэша на стороне .Net часть запросов пойдет без участия 1С в многопоточном режиме, что уменьшит вероятность завершения по таймауту.
На сколько выше или ниже в абсолютных цифрах — это тема отдельного исследования. Для данного метода достаточно знать, что лучше однопоточного HttpListener'а может быть многопоточный (благо .Net это позволяет). И желательно применение кэша на стороне .Net.
2. Полная подконтрольность нужна в некоторых задачах, вот реальный вопрос от пользователей: «Реализована информационная система на базе платформы „1С: Предприятие 8.2“, в системе создан Web-Сервис, на который приходят запросы с необходимой информацией в теге header. Платформа „1С: Предприятие 8.2“ не позволяет считывать информацию в теге header.»
3. В случае с 1С протокол ограничен SOAP, что не гарантирует совместимости с др.платформами. В случае с предложенной технологией протокол SOAP'ом не ограничен, выбирайте любой: JSON, REST, XML или выдумывайте свой. Стандартные случаи хорошо документированы, так как это классы .Net Framework.
4. Не обязательно через веб-сервисы. Скоро предложу на критику еще один прогрессивный метод доступа на замену веб-сервисам.
Полностью согласен, что на полноценный веб-сервер не тянет и лучше сайты делать на IIS или Apache.
Но определенные задачи веб-сервер на стороне 1С все-таки решает: например, работает с оборудованием, мониторит состояние базы.
Потаенный смысл в следующем:
1. Само наличие веб-сервера внутри 1С
2. Полная подконтрольность — возможность управлять заголовками, кукисами и т.д.
3. Вспомогательный функционал, вынесенный в .Net будет многопоточным и эффективным. Например, кэширование ответов на стороне .Net.
4. За счет нескольких прослушивающих потоков меньшая вероятность потерять запрос.
5. Доступен сразу весь функционал .Net: можно возвращать JSON, RSS, REST, рисунки через его объекты. На рисунки можно «на лету» ставить водяные знаки.
ОбъектПодключения = "V82c.Application"; ТекCOMОбъект = Новый COMОбъект(ОбъектПодключения); СтрокаПодключения = "ws=""http://192.168.xxx.xxx/TradeTest"";Usr=""Администратор"";Pwd=""Pass"";"; ТекCOMОбъект.Connect(СтрокаПодключения); ТекCOMОбъект.Visible = Ложь;Чтобы появилась запись в реестре для «V82c.Application» нужно выполнить:
C:\Program Files\1cv82\8.2.xx.xx\bin\1cv8c.exe /RegServerСоответственно для тонкого клиента весь функционал урезан.
HKEY_CLASSES_ROOT\V83.Application
HKEY_CLASSES_ROOT\V83C.Application
1) Значит ли это, что по COM я будут подключаться к неуправляемому приложению по V83.Application, а к управляемому приложению по V83C.Application? При этом функционал в V83C.Application будет намного урезанным — соответствовать функциям тонкого клиента?
2) Могу ли я установив только тонкий клиент под Windows через V83C.Application обратиться к удаленной базе, например, demo-ma.1c.ru?
Есть ли вообще возможность подключения по COM к управляемому приложению, например к тому же demo-ma.1c.ru/ удаленно? И если есть, то какие ограничения накладываются на такие подключения по сравнению с подключением к «толстому» клиенту?
Необычно-экономное использование 1С: Предприятие 8 на Asp.Net-хостинге
Многопоточный веб-сервер для 1С: Предприятие средствами .Net Framework