Где хранится код 1с
Многие спрашивают А где хранится лицензия на 1С: Предприятие 8? или Где посмотреть лицензионный ключ в 1С?
В 1С информацию о полученной лицензии можно посмотреть нажав «Справка» — «О программе»
В разделе Лицензия: сначала идет клиентская лицензия, затем, если это серверный вариант, лицензия сервера 1С
Например будет указан Регистрационный номер комплекта и будет указан путь к файлу лицензии «file://C:/ProgramData/1C/1Cv82/conf/20120430015941.lic».
Начиная с версии платформы 1С:Предприятия — 8.2.15 список сеансов инф. базы в консоли Администрирование серверов 1С:Предприятия содержит колонку с информацией о лицензии, используемой каждым сеансом. Так что учет используемых лицензий аппаратных и программных можно вести в Консоли Администрирования серверов 1С. В средствах программного администрирования имеется свойство License объекта ISessionInfo. В более ранних версиях платформы 1С:Предприятия 8.2 таких средств нет.
ОСОБЕННОСТИ ЛИЦЕНЗИЙ С ПРОГРАММНОЙ ЗАЩИТОЙ
Клиентские программные лицензии разделяются на однопользовательские и многопользовательские.
Однопользовательская лицензия предназначена для установки на компьютер пользователя и разрешает запуск с этого компьютера произвольного количества сеансов с системой "1С:Предприятие 8". Информационные базы в этих сеансах могут быть созданы с различными конфигурациями. Поддерживается работа клиента как в файловом, так в клиент-серверном варианте.
Многопользовательская лицензия устанавливается:
на компьютер сервера "1С:Предприятия" в случае клиент-серверного варианта информационной базы;
на компьютер веб-сервера в случае файлового варианта информационной базы.
Многопользовательская лицензия позволяет запускать не более обозначенного в Лицензионном соглашении количества сеансов с системой "1С:Предприятие". Данная лицензия не привязана к какому-либо компьютеру пользователя, подсчет количества сеансов выполняется на сервере.
В основные поставки, обеспечивающие запуск приложения на одном рабочем месте, а также в клиентскую лицензию на одно рабочее место входит комплект пинкодов для получения одной однопользовательской лицензии (аналог ключа аппаратной защиты на одно рабочее место).
В каждую клиентскую лицензию на 5, 10 и 20 рабочих мест входит по два комплекта пинкодов: для получения соответствующего количества однопользовательских лицензий и многопользовательской лицензии на соответствующее количество рабочих мест. Перед получением первой лицензии из такого продукта необходимо определиться, как ее предполагается использовать:
установить по одной однопользовательской лицензии на определенные компьютеры и запускать с них произвольное количество сеансов с "1С:Предприятием"
или
установить лицензию на сервер и запускать "1С:Предприятие" с произвольных компьютеров, но при этом ограничить количество одновременно запущенных сеансов.
Важно сделать выбор типа клиентской лицензии перед первым получением лицензии, так как получение лицензии по пинкоду для однопользовательской лицензии сделает невозможным получение лицензии по пинкоду для многопользовательской лицензии, и наоборот, получение многопользовательской лицензии сделает невозможным получение из данного комплекта однопользовательской лицензии.
В клиентских лицензиях на 50, 100, 300 и 500 рабочих мест поставляется комплект пинкодов для получения многопользовательской лицензии на соответствующее количество рабочих мест.
Если требуется увеличить число рабочих мест, то следует докупить нужное количество программных лицензий и установить их на компьютеры пользователей либо на сервер. На сервер может быть установлено произвольное количество программных лицензий в любых комбинациях из поставляемых вариантов.
Программная лицензия на сервер устанавливается на компьютер сервера "1С:Предприятия". Как и в лицензиях на сервер с аппаратной защитой, программная лицензия на 64-разрядный сервер поддерживает также работу 32-разрядного сервера.
Если взамен 32-разрядного сервера с программной защитой потребуется использовать 64-разрядный сервер, то для этого необходимо сделать апгрейд, см. далее раздел "Апгрейд лицензии на сервер".
ВНИМАНИЕ: Данная разработка остановлена, публикация оставлена как идея.
Разработал эту конфигурацию для личного пользования, чтобы систематизировать накапливаемый опыт и получать быстрый доступ к собственным наработкам. Минимум самого необходимого функционала, с возможностью хранения не только кода 1С, но также и типичные для 1С типы файлов (такие как .cf, .dt, .epf и .др), а также любые другие файлы, которые будут определены в типах данных.
Возможности конфигурации:
1. В конфигурацию уже встроены предопределенные типы данных:
- Выгрузка информационной базы;
Имеется возможность сохранить файлы из библиотеки в выбранный каталог на компьютере.
2. К типам данных можно добавлять свои, которые будут храниться в файлах, заданного типа.
3. Конфигурация позволяет хранить сопроводительную информацию о хранимых данных:
4. Есть возможность настраивать каталог хранения данных для разных компьютеров. Что позволяет, разместив базу, например, на Яндекс.Диске, пользоваться базой с разных компьютеров.
Данные хранятся на вашем компьютере в отдельном каталоге, который вы укажете в "Настройках каталога хранения данных". Этот каталог. естественно, тоже должен быть общедоступным для тех компьютеров, с которых вы пользуетесь конфигурацией. В указанном каталоге будет создана структура папок, в которой будут храниться все загружаемые в библиотеку файлы. Таким образом, хранятся все файлы отличные от типа данных "Код" и "Произвольный текст" - эти текстовые типы, хранятся непосредственно в базе.
5. Показывается небольшая статистика о хранимых данных в базе:
- Информация о типах хранимых данных;
- Статистика по ключевым словам библиотеки.
При просмотре информации по ключевым словам, можно двойным щелчком мыши перейти к форме списка файлов, с просмотром только тех файлов, которые содержат выбранное ключевое слово.
Замечание по допущенным упрощениям:
Если у вас возникли уточняющие вопросы по работе конфигурации, задавайте их в комментариях. текст публикации обязательно будет дополняться ответами на эти вопросы.
Первоначально стояла задача взаимно-однозначного соответствия (синхронизации ) областей кодов некоторых справочников, номеров документов 1С с идентификаторами таблиц сторонней Базы Данных. Примененный подход показался интересным и получил дальнейшее развитие - это методы работы с Алфавитами, "блочные" коды с расчетом длин блоков, использование Алфавитов-коллекций с кодами символов. Последние могут пригодиться например при передаче Клиент-Сервер "непередаваемых" символов Алфавита.
1. Изменение кода, добавление числа
Это наиболее востребованная операция : к входному числовому или строковому Коду на основе входного Алфавита добавляется Число , полученное преобразуется в выходной Код на основе выходного Алфавита. Реализовано функцией:
Если Код является Числом, производиться суммирование с ДобавитьЧисло, на основе АлфавитИлиТипВыхода производиться преобразование в выходной Код. Если добавляемое число равно 0, тогда это просто преобразования Кода из одного Алфавита в другой (например из "десятичного" в "двоичный", из "русского" в "латиницу" и т.п.).
2. Методы Алфавитов
При работе со сторонними БД (да и с 1С), часто неизвестен Алфавит, на основе которого построены коды той или иной таблицы (таблиц). Здесь может помочь следующая функция:
Так, "пролистав" нужную таблицу (или таблицы) и собрав Коды в массив Строки, создаем Алфавит для данной таблицы (таблиц):
Можно применять эту функцию и на каждом шаге сканирования :
а затем отсортировать:
3. "Блочные" Коды. Изменение, добавление числа.
В некоторых случаях Код-строка состоит из одинаковых блоков определенной длины (подстрок). Так, например, построены битные строки при 8, 16 или 32 битном кодировании, Хэши и т.п. Для преобразования таких строк предназначена функция:
4. Проверка и расчет длин блоков
Для расчета возможных длин блоков в блочных Кодах предназначена функция:
Данная функция используется для проверки-расчета длин блоков в функции Код_БлочныйИзменить(. ). Однако она может использоваться и самостоятельно, например для расчета минимальной длины получаемого кода при перекодировке из одного Алфавита в другой функцией Код_Изменить(. ). Вот так получаем расчетную длину выходного кода:
Иногда пинкоды и ликдата для восстановления лицензий 1С теряются и забываются. Но паниковать не стоит – их можно достаточно просто и быстро восстановить.
Что такое ликдата?
Ликдата (LicData) – данные о компании, которые вводились при первичной активации лицензий 1С. Чтобы восстановить лицензию, необходимо точно ввести ликдату.
При регистрации / восстановлении лицензий данные вводят в такое окно. При регистрации / восстановлении лицензий данные вводят в такое окно.Сделать это можно двумя способами:
Способ 1
Если вы не можете вспомнить данные, которые вводили при активации, то попробуйте отыскать на компьютере файл под названием LicData.txt – в нем и будет находиться нужная информация.
Способ 2
Если файл LicData.txt не получается, либо же содержащиеся в нем данные не подходят, то в ходе активации лицензии нажмите на кнопку «Дополнительно» и снимите галочку в строке «Автоматическое получение».
После этого делайте все, что делаете при обычном восстановлении лицензии вплоть до шага «Способ получения лицензии».
На этом этапе выберите в способе получения «На электронном носителе».
Сохраните полученный файл на компьютер.
Помните, что фирма «1С» обрабатывает письма и запросы по лицензиям только в рабочие дни с 9:30 до 18:00 по МСК. Как правило, ответ приходит в течение дня.
Способ 3
Ликдата содержится в файлах программных лицензий в виде шифра (расшифровку можно сделать с помощью специальной утилиты ring ). Файлы имеют расширение «.lic». Попробуйте найти их, выполнив поиск по маске *.lic.
Активный пинкод
Активный пинкод – это пинкод, который был введен последний раз при активации лицензии. Именно поэтому лучше всего сразу же записывать и сохранять пинкод, чтобы не восстанавливать его в будущем.
Однако, если пинкод все же утерян, то потребуется написать заявление на официальном бланке вашей организации с подписью и печатью. В заявлении укажите регистрационный номер продукта и запросите активный пинкод.
Примерный текст заявления: «Регистрационный номер продукта 8993245908. Просим выслать ответным письмом текущий активный пинкдо».
Помните, что фирма «1С» обрабатывает письма и запросы по лицензиям только в рабочие дни с 9:30 до 18:00 по МСК. Как правило, ответ приходит в течение дня.
Активный пинкод также содержится в файлах программных лицензий в виде шифра (расшифровку можно сделать с помощью специальной утилиты ring ). Файлы имеют расширение «.lic». Попробуйте найти их, выполнив поиск по маске *.lic.
Резервный пинкод
Резервный пинкод – это пинкод, который вводится при установке лицензии, если ключевые параметры компьютера изменились.
Фирма «1С» предоставляет несколько резервных пинкодов, их можно найти на листе с пинкодами или в соответствующем файле (в случае покупки электронной поставки).
Эффективное хранение данных интересует абсолютно всех, кто хоть как-то связан с ИТ. Мы в IaaS-провайдере 1cloud постоянно анализируем опыт коллег — совсем недавно мы обсуждали, как хранят свои данные крупные компании.
Сегодня мы продолжим эту тему и обсудим, как лучше хранить свой код: в одном репозитории или в нескольких. Также мы взглянем на два примера, которые продемонстрируют особенности обоих подходов.
/ фото Dennis Skley CC
Нужно ли сохранять свои исходники в едином, монолитном репозитории или же надо разбить код на блоки и записать их в несколько разных хранилищ? Как правило, это зависит от команды и проекта, над которым она работает. Для начала рассмотрим преимущества и недостатки обоих типов хранения.
Монолитный репозиторий
Обычно первое, что приходит на ум, – это записать весь код в одно хранилище, по крайней мере, на первом этапе: с этого начинает большинство проектов. Репозиторий называют монолитным, если в нем хранится два и более отдельных проекта. Эти проекты слабо или совсем не связаны, а сам репозиторий содержит чересчур много файлов, коммитов и других объектов.
Главное преимущество хранения кода в едином репозитории заключается в том, что так гораздо проще организовать совместную работу с кодом. Мы можем создать один общий проект, состоящий из нескольких подпроектов, а затем связать эти подпроекты, как нам удобно.
Если разработчику нужно изменить код или принцип связи между частями проекта, легче это сделать, когда у него есть доступ к коду всего проекта. Предположим, мы пишем систему для онлайн-торговли, которая строится на микросервисной архитектуре. Когда мы пишем код для сервиса корзины и нам нужно просмотреть или изменить общую библиотеку, мы сразу можем к ней перейти: нам не нужно открывать другой проект или репозиторий. Раз мы можем редактировать зависимости, значит, можем быстрее проводить глобальные изменения, не заботясь об управлении версиями.
Когда весь код хранится в одном месте, нам остается лишь запустить процесс и, например, следить, как изменения в общей библиотеке влияют на работу с корзиной. Объекты доступны в любое время из любого места, изменения проходят быстро и безболезненно. Но не все так гладко.
Зачастую руководители выбирают единый репозиторий просто потому, что с ним будет проще, и они якобы знают, что делают. Из-за подобных решений учащаются случаи, когда разработчики вносят изменения в те части кода, к которым им не следовало бы прикасаться. И это легко сделать, если у вас есть доступ ко всему коду, а у проекта нет явно очерченных границ.
Много проблем возникает при развертывании и масштабировании. Таким образом, теряется целостность системы. Чем больше объем репозитория, тем медленнее будет осуществляться проверка. Если же код хранится в нескольких репозиториях, процесс можно распараллелить, а ошибки, возникающие в одной из частей проекта, не смогут обрушить работу всех сервисов.
Вывод: Если у вас небольшая команда или вы не собираетесь расширяться, логичнее хранить весь код в одном месте. Использовать единый репозиторий удобно и в том случае, если вы не работаете с микросервисами, а разрабатываете монолитное приложение.
Несколько советов по смягчению недостатков монолитных репозиториев в Git (большие размеры файлов, количество коммитов и указателей) здесь предлагает пользователь Хабра.
Хранение кода в нескольких репозиториях
Часть проблем, возникающих при наличии единого репозитория, решается введением нескольких хранилищ. Если говорить о микросервисах, то в идеале для каждого сервиса должен быть свой репозиторий. Этот подход облегчает процесс контроля версий: внесли изменения в библиотеке – обновили ее версию, подправили код сервиса – обновили его версию.
Наличие нескольких репозиториев вынуждает писать код так, как если бы его собирались просматривать сторонние разработчики (что, кстати, вполне вероятно). Вместо того, чтобы думать о правках в коде как о масштабном изменении всей программы, разработчик начинает размышлять, как изменить один модуль, не затрагивая работу всей системы. В итоге связанность между модулями ослабевает.
Это позволяет развертывать их независимо друг от друга. Если наш сервис оформления заказов работает с обеими версиями протокола, мы можем развернуть его еще до того, как будет исправлен код корзины. Такой подход требует наличия высокого уровня дисциплины.
Вывод: Если ваша команда достаточно опытная, чтобы поддерживать регулярное обновление версий и работать с микросервисами, или в ней много человек, которые организованы в небольшие группы, то хранить код лучше в нескольких репозиториях. Подход будет также полезен при обучении новых сотрудников, которые станут более дисциплинированными, если будут следовать правилам обновления версий и сохранять границы между сервисами.
Как хранят код Google и Kiln
Судя по сделанным выводам, большинство компаний, особенно крупных, предпочло бы работать с несколькими репозиториями. Даже если это так, из этого правила есть как минимум одно большое исключение. Как ни странно, десятки тысяч разработчиков Google сегодня используют монолитный репозиторий, где хранится около двух миллиардов строк кода. Чтобы сохранить такие масштабы, Google пришлось разработать систему контроля версий, более известную как Piper.
Доступ к Piper организован с помощью системы Clients in the Cloud (CitC), состоящей из облачного хранилища и файловой системы FUSE для Linux. У каждого разработчика есть рабочая среда, в которой хранятся измененные им файлы. Все записанные файлы хранятся в CitC в виде снэпшотов, что позволяет при необходимости «откатить» работу на несколько этапов назад.
Встроенный в CitC инструмент для поиска кода CodeSearch позволяет вносить мелкие исправления в код, а также передавать измененный код на проверку с возможностью автокоммита: если проверка пройдена, проводится тест, после которого система сама выставляет коммит.
Основу модели монолитного репозитория составляет подход, имеющий название trunk-based development («стволовая разработка»). Основная (trunk) линия представляет собой последнюю версию кода, изменения в которую вносятся разово и последовательно. Сразу после коммита новая версия кода доступна всем пользователям Piper, то есть, по сути, у разработчика перед глазами всегда свежая версия кода.
Что касается добавления функционала, то и старый, и новый код существуют параллельно друг другу, а их использование контролируется с помощью конфигурационных флагов. Этот подход позволяет избегать проблем, которые возникают из-за слияния изменений.
Пользователи Stack Overflow советуют хранить код в едином репозитории, даже когда есть возможность разбить его на несколько хранилищ. Для этого существуют такие инструменты, как подмодули в Git, внешние объекты в Subversion и субрепозитории в Mercurial.
Все они предназначены для построения внутренней иерархии большого проекта, и их можно использовать для выделения отдельных модулей: достаточно каждый проект поместить в отдельный репозиторий, а затем использовать подмодули для включения нужных проектов на определенном уровне иерархии.
Кроме того, в Git есть возможность создавать независимые ветви, которые называют сиротскими (orphan). Они не имеют ничего общего друг с другом и сохраняют исключительно свою историю. Так создается новая сиротская ветвь:
Каждый отдельный проект можно представить отдельной сиротской веткой. По какой-то причине в Git нужно проводить такую очистку после создания этой ветви:
Перед очисткой убедитесь, что выставлен соответствующий коммит. После нее веткой можно смело ею пользоваться.
Другой вариант – создать несколько репозиториев и закинуть эти ветки в каждый из них (имена репозиториев не должны совпадать):
Другого мнения о хранении кода придерживаются разработчики Kiln, в свое время перешедшие с монолитного репозитория Subversion на мультирепозиторий Mercurial. Их проект разделен на пять частей: exe-клиенты, сервер для взаимодействия клиентов (Reflector), сайт, биллинговая система и библиотека Aadvark.
Для каждой части они создали по два репозитория – devel и stable. В первый попадают новые фичи, которые спустя время переходят во второй, а исправленные баги, наоборот, сначала помещаются в stable, а затем как новые функции возвращаются в devel. Для синхронизации используются теги. В Mercurial они представляют собой метаданные репозитория.
Например, чтобы развернуть новую версию сайта, берутся репозитории website-stable и aadvark-stable. К каждому прикрепляется тег, допустим, Website-000123. Затем запускается процесс сбора билда, который клонирует оба репозитория с сервера в директорию сборки и выполняет команду hg up –C Website-000123 для переключения локальной копии на нужный тег. После сбора билда производится развертывание.
Заключение
К выбору того, где и как хранить код, следует подходить осмысленно, а это требует определенных усилий. Нельзя сказать, что один подход однозначно лучше другого. Нужно учитывать состав команды, ваш опыт и стоящие перед вами цели, и уже на основе этого принимать решение. Тем более, при желании всегда можно перейти от одного репозитория к нескольким, и наоборот.
Так или иначе, любое понимание приходит с опытом. Иногда полезно набить шишек, чтобы потом знать, чего стоит опасаться и какие способы наверняка сработают. Поэтому по-настоящему понять, что больше подходит вашей команде, поможет время и желание каждого внести максимальный вклад в развитие продукта.
Читайте также: