Процесът на фонова работа 8.3 се срина. Планирани и фонови задачи (1Cv8)

Позволява ни да извършваме всякакви изчисления в системата незабелязано от потребителя, тоест във фонов режим. Освен това този механизъм ни позволява да паралелизираме процеса на изчисление. Можем дори да паралелизираме процедурата, която ще бъде изпълнена. За да направи това, нашето фоново задание трябва да изпълни още няколко фонови задания. В този случай процесите са паралелизирани и, ако имаме многопроцесорна, многоядрена система, нашият алгоритъм ще работи ефективно. След като стартираме няколко процеса, можем да кажем на системата, че трябва да изчакаме изпълнението на тези процеси да приключи, за да консолидираме по някакъв начин резултата.

Например, в типичните конфигурации, докато потребителят работи, се изпълняват различни видове фонови сервизни задачи. Това може да се докаже от записи в дневника, който записва факта, че са извършени такива действия. Освен това това по никакъв начин не засяга работата на потребителя, той просто не ги забелязва.

В идеалния случай фоновата работа се изпълнява във вариант клиент-сървър, като в този случай цялото натоварване се прехвърля към сървъра. Що се отнася до версията на файла, работата фонова работавъзможно, но има някои особености.

Това ще даде системата, ако не вземете предвид тези функции и изпълните фонова задача във файловата версия на информационната база.

Фоновата задача на 1C има някои ограничения.Тъй като се извършва от страната на сървъра, няма възможност за интерактивна работа с потребителя. Например, не можете да покажете съобщение, добре, като цяло, някаква информация. Всички тези данни трябва да се съхраняват в информационната база и допълнително да се обработват по някакъв начин.

Като се свържете с помощника по синтаксис, можете да получите по-подробна информация за фоновите задачи на 1C. Тук трябва да се отбележи, че този обект е чисто програмен и не се съхранява в базата данни по никакъв начин. Тоест създаваме екземпляр на класа, инициализираме свойствата и го стартираме за изпълнение.

Какви инструменти имаме за управление на фонови задачи? Този инструмент е обект на метаданни "BackgroundQuest Manager". Този обект има метод "Бягай", използвайки този метод, фоновото задание току-що стартира.

Има следните опции:
"Име на метод"- името на процедурата или функцията, която трябва да бъде изпълнена и трябва да бъде процедура или функция от контекста на сървъра;

"Настроики"- масив от параметри, чийто брой елементи трябва да съответства на броя на параметрите на нашата процедура / функция, посочени в параметъра "Име на метод";

"Ключ"- определен ключ за уникалност, който е линия, по която системата разбира дали трябва да се стартира фонова задача или такава вече е стартирана;

"Име"- тук можете да посочите произволно описание на нашия метод.

Връщаната стойност е обект „Фонова мисия“ A, който съдържа името на текущия метод, текущия ключ и още няколко свойства и методи. Един от тези методи е методът "Изчакайте завършване". Целта му е да можем да кажем на системата да не прави нищо, докато фоновата работа не приключи.

Основна задача 1C 8.2, 8.3 - Пример за използване

Нека дадем пример за работа с фонови задачи 1C. Първо, ще създадем прост алгоритъм, който за кратко ще зареди системата 1C по такъв начин, че да не можем да направим нищо в момента.

За това:

1. Нека създадем общ модул "BackgroundHandlers", който ще бъде компилиран от страната на сървъра;

2. Опишете процедурата за експорт в него „Създаване на фоново изчисление (параметър)“, който приема единичен параметър тип низ;

Процедура PerformBackgroundComputation(Параметър) Export StartTime = CurrentDate() ; Докато CurrentDate() - Начален час< = 6 Цикл КонецЦикла ; КонецПроцедуры Процедура КнНажатие() ОбработчикиФоновыхЗаданий. ПроизветиФоновоеВычисление(„някакъв параметър“) ; EndProcedure

Готов. Сега, когато се започне обработка и се натисне бутонът, системата замръзва за няколко секунди, през които нищо не може да се направи. Точно това трябваше да направим.

Сега ще гарантираме, че тези изчисления се извършват във фонов режим, тоест, че фоновата задача 1C 8.2, 8.3 се изпълнява, но това не ни пречи.

За това:

1. При обработка, в събитието за щракване на бутон, напишете следния код.

Процедура KnPress() Параметри = Нов масив; Настроики. Добавяне ( „някакъв параметър“) ; BackgroundJob. Изпълни ( "BackgroundJobHandlers.PerformBackgroundComputation", Параметри, Нов UniqueIdentifier, "Тест") ; EndProcedure

Тук подаваме името на процедурата на общия модул като първи параметър и масива от параметри като втори. Третият параметър е предаване на уникален ключ, а четвъртият параметър е описание на нашата процедура.

Вероятно нито една сериозна конфигурация на 1C 8.3 или 8.2 не може да мине без използването на планирани и фонови задачи. Те са много удобни, тъй като ще се изпълняват по ясно определен график без намеса на потребител и програмист.

Например, трябва да обменяте данни с друга програма веднъж на ден. Използвайки рутинни и фонови задачи, 1C ще може да извършва тези действия самостоятелно, например в извънработно време. Този метод няма да повлияе по никакъв начин на работата на потребителите и ще спести време.

Първо, нека разберем какво означават и как се различават:

• Планирана задачави позволява да изпълнявате всякакви конкретни действия според предварително конфигуриран график.
• Фонова работае обект, който съдържа действията, които трябва да бъдат извършени.

Да предположим, че нашата компания продава нещо и има собствен уебсайт с цени. Веднъж на ден искаме да ги разтоварим, за да поддържаме уместност.

Отворете конфигурацията и добавете планирана задача.

Задаване на свойства

Помислете за най-важните параметри, които трябва да бъдат попълнени в неговите свойства.

• В полето " Име на метода» се избира процедурата на някакъв конкретен общ модул, който ще се изпълнява директно. Той ще посочи всички действия за качване на цени на нашия уебсайт. Имайте предвид, че изпълнението ще се извърши на сървъра. Това е логично, тъй като рутинните операции се извършват без намеса на потребителя.
• Планираната задача може да бъде деактивирана или активирана според нуждите. Няма нужда да променяте графика му всеки път. За да направите това, в палитрата със свойства поставете или премахнете отметката от " Използване».
• Друга важна настройка е дали тази планирана задача ще бъде предварително определени, или не. Предварително зададените планирани задачи се изпълняват автоматично. Ако този флаг не е зададен, тогава ще трябва да ги стартирате програмно или да използвате обработката на "Job Console" с ITS.
• Можете също да посочите броя на повторенията и интервала между тяхпри катастрофа. Ненормалното завършване се отнася до онези ситуации, когато задачите не са завършени поради грешка.

Настройка на графика

Последната стъпка е да настроите график за нашето качване на сайта, като използвате подходящата хипервръзка в палитрата със свойства.

Ще видите типична настройка на графика в 1C 8.3. Тук няма нищо сложно. Като част от този примернастроихме стартирането на нашето качване на цени на сайта всеки ден от пет до седем сутринта. В случай, че планираната задача няма време да се изработи преди 7:00, тя ще бъде изпълнена на следващия ден.

Блокиране на планирани задачи

Стартирайте стандартната помощна програма за администриране на 1C Enterprise Server и отворете свойствата на информационната база, където сте създали планираната задача (за версиите на 1C клиент-сървър).

В прозореца, който се отваря (след въвеждане на потребителско име и парола за достъп до IB), проверете дали флагът на елемента „Блокирането на планирани задачи е активирано“ не е зададен. Ако срещнете ситуация, в която задачата не работи, първо проверете тази настройка.

По същия начин можете напълно да деактивирате планираните задачи в 1C 8.3. За да деактивирате определени фонови задачи, можете да използвате обработката на „Конзолата за фонови задачи“, вградена в последните версии.

Фонови и планирани задания във файлов режим

В този режим настройката и изпълнението на тези задачи е много по-трудно за организиране. Най-често допълнителен Сметка, чиято сесия винаги ще бъде отворена.

Активирането на планираните задачи в този случай се извършва с помощта на метода "PerformProcessingTasks()".

Можете също да използвате следната конструкция:

Името на процедурата трябва да бъде името на процедурата на клиента, която ще бъде изпълнена. Интервалът показва колко секунди ще отнеме изпълнението. Параметърът "Веднъж" не е задължителен. Отразява дали дадената процедура ще се извърши веднъж или няколко пъти.

Проследяване на грешки във фонови задачи

Вижте напредъка на фоновите задания, както и наличността възможни грешкиможе да бъде в регистъра. Във филтъра задайте селекцията на приложението „Фонова задача“ и, ако е необходимо, изберете важността на интереса, например само „Грешки“.

Дневникът ще покаже всички записи, които отговарят на вашия избор, с коментар, който можете да използвате, за да разберете причината за грешката.

Механизъм на работа

Механизмът за работа е проектиран да изпълнява всяко приложение или функционалност по график или асинхронно.

Механизмът за работа изпълнява следните задачи:

• Възможност за определяне на рутинни процедури на етап конфигуриране на системата;
• Изпълнение на определени действия по график;
• Изпълнението на извикване на дадена процедура или функция е асинхронно, т.е. без да чака завършването му;
• Проследяване на напредъка на конкретна работа и получаване на нейния статус на завършеност (стойност, показваща успеха или неуспеха на нейното изпълнение);
• Получаване на списък с текущи задачи;
• Възможност за изчакване на изпълнението на една или повече задачи;
• Управление на работата (възможност за анулиране, блокиране на изпълнението и др.).

Работният механизъм се състои от следните компоненти:

• Метаданни на планирани задачи;
• Планирани задачи;
• Фонови работни места;
• Планировчик на задачи.

Фонови задачи - предназначени за асинхронно изпълнение на задачи на приложението. Фоновите задачи се изпълняват с помощта на вградения език.

Планирани задачи - предназначени за изпълнение на задачи на приложението по график. Планираните задачи се съхраняват в информационна базаи се създават въз основа на метаданните, дефинирани в конфигурацията. Метаданните за планирано задание съдържат информация като име, метод, използване и т.н.

Планираната задача има график, който определя кога трябва да се изпълни методът, свързан с планираната задача. Графикът, като правило, се задава в информационната база, но може да бъде зададен и на етапа на конфигурация (например за предварително дефинирани планирани задачи).

Планировчикът на задачи се използва за планиране на изпълнението на планирани задачи. За всяко планирано задание планировчикът периодично проверява дали Текущата датаи времеви график на планираната задача. Ако съвпада, планировчикът планира тази задача да се изпълни. За да направи това, според тази планирана задача, планировчикът създава фонова задача, която изпълнява действителната обработка.

Фонови задачи

Фоновите задачи са полезни за извършване на сложни изчисления, когато резултатът от изчислението може да бъде получен след дълго време. Машината за работа има средствата да извършва такива изчисления асинхронно.

Фоновото задание има свързан метод, който се извиква, когато се изпълнява фоновото задание. Метод на фоново задание може да бъде всяка процедура или функция на неглобален споделен модул, която може да бъде извикана на сървъра. Параметрите на фоновото задание могат да бъдат всякакви стойности, които могат да бъдат предадени на сървъра. Параметрите на фоново задание трябва точно да съвпадат с параметрите на процедурата или функцията, която извиква. Ако методът на фоновото задание е функция, нейната върната стойност се игнорира.

Фоновата работа може да има ключ - произволна стойност на приложението. Ключът въвежда ограничение за стартиране на фонови задания - само едно фоново задание може да бъде изпълнено за единица време с определена стойност на ключ и определено име на метода на фоновото задание (името на метода се състои от името на модула и името на процедурата или функцията). Ключът ви позволява да групирате фонови задания, които имат едни и същи методи според определен атрибут на приложение, така че в рамките на една група да не се изпълнява повече от едно фоново задание.

Фоновите задачи се създават и управляват програмно от всяка връзка. На всеки потребител е разрешено да създава фоново задание. В същото време се изпълнява от името на потребителя, който го е създал. Потребител с административни права или потребителят, който е създал тези фонови задачи, има право да получава задачи, както и да чака тяхното завършване от всяка връзка.

Фоновото задание е изцяло обект на сесия, но не принадлежи към никоя потребителска сесия. За всяка задача се създава специална системна сесия, която се изпълнява от името на потребителя, който е направил повикването. Фоновите задачи нямат постоянно състояние.

Едно фоново задание може да създаде други фонови задания. Във версията клиент-сървър това ви позволява да паралелизирате сложни изчисления в работните процеси на клъстера, което може значително да ускори процеса на изчисление като цяло. Паралелизирането се осъществява чрез създаване на няколко дъщерни фонови задания, като се чака всяко от тях да завърши в основното фоново задание.

Успешните или неуспешните фонови задачи се съхраняват за 24 часа и след това се изтриват. Ако броят на изпълняваните фонови задания надвиши 1000, тогава най-старите фонови задания също се изтриват.

Планирани задачи

Планираните задачи се използват, когато трябва да извършвате определени периодични или еднократни действия в съответствие с графика.

Планираните задачи се съхраняват в информационната база и се създават въз основа на метаданните на планираната задача, дефинирана в конфигурацията. Метаданните дефинират такива параметри на планирана задача като: извикан метод, име, ключ, възможност за използване, знак за предварително определяне и т.н. за изпълнение на планирана задача и т.н.

Създаване и управление рутинни задачисе изпълнява програмно от всяка връзка и е разрешено само на потребители с администраторски права.

Забележка. Когато работите във файловата версия, е възможно да създавате и редактирате планирани задачи, без да стартирате програмата за планиране на задачи.

Планираната задача е свързана с метод, който се извиква, когато планираната задача се изпълни. Метод на планирано задание може да бъде всяка процедура или функция на неглобален споделен модул, който може да бъде извикан на сървъра. Параметрите на планираното задание могат да бъдат всякакви стойности, които могат да бъдат предадени на сървъра. Параметрите на планирано задание трябва точно да съвпадат с параметрите на процедурата или функцията, която извиква. Ако методът за планирано задание е функция, тогава нейната върната стойност се игнорира.

Насрочена задача може да има ключ - произволна приложена стойност. Ключът въвежда ограничение за стартиране на планирани задачи, тъй като на единица време, сред планираните задачи, свързани със същия обект на метаданни, може да бъде изпълнена само една планирана задача с определена стойност на ключ. Ключът ви позволява да групирате планирани задачи, свързани с един и същ обект на метаданни, според определен атрибут на приложение, така че не повече от една планирана задача да се изпълнява в рамките на една група.

По време на конфигурирането можете да дефинирате предварително зададени планирани задачи. Предварително зададените планирани задания не се различават от обикновените планирани задания, освен че не могат да бъдат изрично създадени или изтрити. Ако метаданните на планираната задача са зададени на знак за предварително дефинирана планирана задача, тогава при актуализиране на конфигурацията автоматично ще бъде създадена предварително зададена планирана задача в информационната база. Ако предварително дефинираното квадратче за отметка е изчистено, предварително дефинираната планирана задача ще бъде автоматично изтрита в информационната база, когато конфигурацията се актуализира. Първоначалните стойности на свойствата на предварително дефинирана планирана задача (например график) са зададени в метаданните. В бъдеще, когато приложението работи, те могат да бъдат променяни. Предварително зададените планирани задачи нямат параметри.

Графикът на планираното задание определя в кои моменти трябва да започне планираното задание. Графикът ви позволява да зададете: дата и час на начало и край на задачата, период на изпълнение, дни от седмицата и месеци, в които трябва да се изпълнява планираната задача и т.н. (вижте описанието на вградения на езика).

Примери за планирани графици на задачи:

Всеки час, само един ден	Retry PeriodDays = 0, Retry PeriodDuringDay = 3600
Всеки ден по веднъж на ден	Retry PeriodDays = 1, Retry PeriodDuringDay = 0
Един ден, един път	Дни на период за повторен опит = 0
През ден веднъж на ден	Дни на период за повторен опит = 2
На всеки час от 01.00 до 07.00 всеки ден	Дни на период за повторен опит = 1 Период на повторен опит през деня = 3600 Начален час = 01.00 Краен час = 07.00
Всяка събота и неделя от 09.00ч	Дни на период за повторен опит = 1 Дни от седмицата = 6, 7 Начален час = 09.00ч
Всеки ден минава една седмица, седмица	Дни на период за повторен опит = 1 Период седмици = 2
Еднократно в 01.00 ч	Начален час = 01.00
Последен ден от всеки месец в 9:00ч.	Дни на период за повторен опит = 1 Ден в месеца = -1 Начален час = 09.00ч
Пети всеки месец в 9:00	Дни на период за повторен опит = 1 Ден В Месеца = 5 Начален час = 09.00ч
Всяка втора сряда от месеца в 9:00 ч	Дни на период за повторен опит = 1 Ден от седмицата в месеца = 2 Дни от седмицата = 3 Начален час = 09.00ч

Можете да проверите дали дадена задача се изпълнява за дадена дата (методът RequiredExecution на обекта ScheduledTasks Schedule). Планираните задачи винаги се изпълняват от името на конкретен потребител. Ако потребителят на планираната задача не е посочен, тогава изпълнението се извършва от името на потребителя по подразбиране с администраторски права.

Планираните задачи се изпълняват с помощта на фонови задачи. Когато планировчикът определи, че планирана задача трябва да бъде стартирана, автоматично се създава фонова задача въз основа на тази планирана задача, която извършва цялата по-нататъшна обработка. Ако тази планирана задача вече се изпълнява, тя няма да бъде стартирана отново, независимо от нейния график.

Планираните задачи имат възможност за рестартиране. Това е особено вярно, когато трябва да се гарантира, че методът на планираната задача ще бъде изпълнен. Планирана задача се рестартира, когато е прекратена необичайно или когато работният процес (във версията клиент-сървър) или процесът на клиента (във файловата версия), на който е изпълнявана планираната задача, е прекратен необичайно. В планирана задача можете да посочите колко пъти трябва да се рестартира, както и интервала между рестартиранията. При внедряването на метода на рестартируемо планирано задание трябва да се има предвид, че когато се рестартира, изпълнението му ще започне отначало, а не ще продължи от момента, в който се срине.

Важно е да запомните това крайно временяма непременно да завърши фоновата работа в определеното време. Някои твърдения:

* Фоново задание може да игнорира собственото си автоматично анулиране, ако не е замръзнал, но продължава да работи тази причиначе не всички операции на платформата могат да бъдат отменени. Ако се извърши цикличен кодвграден език, заданието може да бъде отменено, в противен случай не. Всичко зависи от това какво върши работата. * Краен час - границата, в рамките на която една задача може да започне и да не завърши? * Принудителното завършване на заданието връща промените до момента, в който транзакцията е започнала?

Особености при изпълнение на фонови задачи във файлови и клиент-сървърни версии

Механизмите за изпълнение на фонови задачи във файловата и клиент-сървърната версия са различни.

• Във файловата версия трябва да създадете специален клиентски процес, който ще изпълнява фонови задачи. За да направите това, функцията за глобален контекст ExecuteJobProcessing трябва да се извиква периодично в клиентския процес. Само един клиентски процес на информационна база трябва да обработва фонови задания (и следователно да извиква тази функция). Ако не е създаден клиентски процес за обработка на фонови задания, тогава при програмен достъп до машината за задания ще се генерира грешката „Мениджърът на задания не е активен“. Не се препоръчва използването на клиентския процес, който обработва фонови задания за други функции.

След стартиране на клиентския процес, който обработва фоновите задания, се дава възможност на други клиентски процеси програмен достъпкъм механизма на фоновата работа, т.е. може да изпълнява и управлява фонови задания.

Във версията клиент-сървър планировчикът на задачи се използва за изпълнение на фонови задачи, който физически се намира в мениджъра на клъстера. Планировчикът за всички поставени на опашка фонови задания получава най-малко натоварения работен процес и го използва за изпълнение на съответното фоново задание. Работният процес изпълнява заданието и уведомява планировчика за резултатите от изпълнението.

Във версията клиент-сървър е възможно да се блокира изпълнението на планирани задачи. Блокирането на изпълнението на планирани задачи възниква в следните случаи:

• В информационната база е зададено изрично блокиране на планирани задачи. Заключването може да се настрои чрез клъстерната конзола;
• В информационната база е зададен блок за връзка. Заключването може да се настрои чрез клъстерната конзола;
• Методът SetExclusiveMode() беше извикан от вградения език с параметъра True;
• В някои други случаи (например при актуализиране на конфигурацията на базата данни).

Създаване на метаданни за планирано задание

Преди да създадете програмно планирана задача в информационната база, трябва да създадете обект на метаданни за нея.

За да създадете обект с метаданни за планирано задание в конфигурационното дърво в клона Общи за клона Планирани задания, изпълнете командата Добавяне и попълнете следните свойства на планираното задание в палитрата със свойства:

Име на метода - Посочете името на метода за планирано задание.

Ключ - задайте произволна стойност на низ, която ще се използва като ключ на планираната задача.

График - определя графика на планираната задача. За да генерирате график, щракнете върху връзката „Отвори“ и задайте необходимите стойности във формуляра за график, който се отваря.

Разделът Общи определя началната и крайната дата на задачата и режима на повторение.

Разделът "Ежедневно" определя дневния график за задачата.

Посочете графика:

• начален и краен час на задачата;
• крайното време на задачата, след което тя ще бъде изпълнена принудително;
• период на повторение на задачата;
• продължителността на паузата между повторенията;
• продължителност на изпълнение.

Допуска се произволна комбинация от условия.

Седмичният график на задачата е посочен в раздела Седмично.

Поставете отметки в квадратчетата за дните от седмицата, в които ще се изпълнява задачата. Ако искате да повторите заданието, посочете интервала за повторен опит в седмици. Например, задачата се изпълнява след 2 седмици, стойността на повторение е 2.

В раздела "Месечно" е посочен месечният график на задачата.

Поставете отметки в квадратчетата за месеците, в които ще се изпълнява задачата. Ако е необходимо, можете да посочите конкретен ден (месец или седмица) на изпълнение от началото на месеца / седмицата или края.

Използване - ако е зададено, задачата ще се изпълнява по график.

Предварително зададено - ако е зададено, работата е предварително дефинирана.

Брой повторения при срив - Указва броя на повторните опити при срив.

Интервал на повторен опит при срив - Указва интервала на повторен опит при срив. Примери

Създаване на фоново задание „Актуализиране на индекса за търсене в пълен текст“:

BackgroundJobs.Run("UpdatingFullTextSearchIndex");

Създаване на планирана задача „Възстановяване на последователности“:

График = Нова ScheduleRegulationTask; Schedule.RepeatPeriodDays = 1; Schedule.RepeatPeriodDuringDay = 0;

Задача = ScheduledTasks.Create ScheduledTask("RestoringSequences"); Task.Schedule = График; Task.Write();

Конзола за работа

Обработка с ITS, управлява планирани задачи:

Работете с планирани задачи

Работни обекти

Обектите на работа не се препращат, но се съхраняват в базата данни в някакво специално хранилище.

Ако флагът "Предварително зададен" е активиран в метаданните, тогава такъв обект се създава автоматично при стартиране на 1C:Enterprise и винаги съществува точно в един екземпляр. Такъв обект не може да бъде изтрит.

Ако флагът "Предварително дефиниран" не е зададен, тогава обектите на такава задача се създават и изтриват програмно, като се посочват графикът и параметрите.

Получаване на списък със задачи

Списъкът със задачи може да бъде получен по метода GetRegularAssignmentsглобален мениджър по работа Планирани задачи

Мениджър на планирани работни места

GetScheduledJobs (GetScheduledJobs)

Синтаксис:

GetRegular Tasks(<Отбор>)

Настроики:

<Отбор>(по избор)

Тип: Структура. Структурата, която определя селекцията. Стойностите на структурата могат да бъдат: UniqueIdentifier, Key, Metadata, Predefined, Usage, Name. Ако изборът не е зададен, се получават всички планирани задачи.

Ако филтрирате по метаданни, можете да укажете или обекта с метаданни за планирано задание, или неговото име като стойност на метаданни.

Върната стойност:

Тип: масив.

Описание:

Получава масив от планирани задачи за посочения избор. Получаването на планирани задачи е възможно само за администратора.

Наличност:

Scheduled = ScheduledTasks.Get ScheduledTasks(Selection);

За всеки планиран от планиран цикъл NewLine = ScheduledTasksList.Add(); NewString.Metadata = Scheduled.Metadata.View(); NewLine.Name = Scheduled.Name; NewString.Key = Scheduled.Key; NewString.Schedule = Scheduled.Schedule; NewString.User = Regular.UserName; NewString.Predefined = Scheduled.Predefined; NewString.Usage = Regulatory.Usage; NewString.Identifier = Scheduled.UniqueIdentifier;

LastTask = Scheduled.LastTask; Ако LastQuest<>Undefined Then NewString.Running = LastTask.Start; NewString.Status = LastJob.Status; EndIf; EndCycle;

Създаване

Създаден от метода CreateRegularTask на диспечера на планираните задачи:

ScheduledJob = ScheduledJobs.Create ScheduledJob(MetadataChoice);

Scheduled Task.Name = Име; ScheduledTask.Key = Ключ; ScheduledTask.Use = Използване; ScheduledTask.UserName = UsersChoice; ScheduledTask.Number of RepetitionsWhen Crashing = Брой повторения при срив; ScheduledTask.RetryIntervalOnAccident = RetryIntervalOnAccident; ScheduledTask.Schedule = График; ScheduledTask.Write();

TaskObject = ScheduledTasks.Create ScheduledTask("ExecuteExchange");

TaskObject.Name = Име; JobObject.Use = вярно;

Обектът на заданието има поле "Параметри", в което се задават параметрите на метода:

ScheduledJob

Настроики(Параметри)

Употреба:

Четене и писане.

Описание:

Тип: масив. Масив от параметри на планирана задача. Броят и съставът на параметрите трябва да съответстват на параметрите на метода на планираната задача.

Наличност:

сървър, дебел клиент, външно присъединяване.

Забележка:

Възможността за четене и писане е достъпна само за администратора.

Премахване

Изтрит от метода Delete() на обекта на заданието:

ScheduledTask.Delete();

Получаване на обект за работа

• списък чрез метода GetRegularTasks:

Scheduled = ScheduledTasks.Get ScheduledTasks(Selection);

• чрез метода FindByUniqueID на мениджъра на задачи:

Задача = ScheduledTasks.FindBy UniqueIdentifier(UID);

В тази статия ще опиша моя, досега малък, опит в организирането на обмен на данни чрез универсалния формат EnterpriseData.

В моя случай обменът е конфигуриран между конфигурациите „Trade Management 11.2“ (наричани по-долу UT) и „Enterprise Accounting 3.0.43“ (наричани по-долу BP). Обменът е еднопосочен, от UT към BP. Преди актуализирането на Trade Management 11.1 до версия 11.2 обменът на данни беше конфигуриран с помощта на конфигурацията Data Conversion 2.0. Въпреки това, след преминаване към "11.2" в "Управление на търговията", се появиха грешки по време на работата на потребителите. Процедурата за актуализиране на правилата за обмен беше проведена, но това не даде резултат. Дебъгерът показа, че проблемът е в обмена на данни. Беше решено да се премахне настройката за обмен на данни и в двете конфигурации и да се настрои отново.

И "Търговски мениджмънт", и "Счетоводство на предприятието" работят при нас във версия клиент-сървър. Започнах да настройвам синхронизация с UT. Изпълних го по такъв начин, че данните бяха разтоварени от UT във файл. Това е синхронизация през мрежовата директория. В BP конфигурирах обмена по такъв начин, че никакви данни не бяха разтоварени от BP.

Грешка при извикване на контекстен метод (Validate): Грешка при валидиране на XDTO данни:
Структурата на обекта "/Банкова сметка на контрагента/Банка" не съответства на типа: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
Проверка на свойството "BIC":
форма: елемент
име: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIC
Тип:
Липсва задължително свойство
Обект: Договор с контрагент № ...

За да анализирам грешката, щракнах върху иконата „Състав на данните за изпращане“ и в списъка с контрагенти, регистрирани за изпращане на договори, намерих договора, по който се появи грешката. Отвори договора, запомни банковата сметка на контрагента, посочена в договора. След това преминах към банкови сметки, регистрирани за доставка. Оказа се, че търсеният акаунт не е в списъка с регистрирани. Пренасочих проблемната банкова сметка и договор. След това ръчно регистрирайте необходимата банкова сметка.

Опитах отново да синхронизирам данни от UT. Този път данните бяха качени успешно. IN мрежова папкаобразувани XML файл, съдържащ данни за прехвърляне от UT към BP.

Следващата стъпка е да качите данните от файла в Счетоводен отдел на предприятието. В конфигурацията „Счетоводство на предприятието“ щракнах върху бутона „Синхронизиране“, формата за обработка се отвори със съобщението „Анализът на данните е в ход“. Малко по-късно съобщението се промени на „Данните се качват“. В същото време индикаторът и броячът показаха, че повече от 80 хиляди обекта се разтоварват от BP. Това ме обърка, защото в настройките посочих, че нищо не трябва да се разтоварва от захранването. Обработката отне много време и завърши с грешка:

Събитие: Комуникация
(CommonModule.LongOperations.Module(371)): Работният процес на фоново задание се срина
ThrowException(ErrorText);

За да локализирам грешката, се опитах да променя настройките за синхронизация и опциите за работа на базата на BP. В резултат на това, когато преобразувах базата данни във файлова версия, системата работи адекватно: отвори се формулярът за сравняване на две бази данни. След съпоставяне на обектите първоначалната синхронизация беше успешна. След това отново прехвърлих базата данни във версията клиент-сървър.

С по-нататъшното "пускане" на синхронизация беше необходимо да се направят някои промени в правилата за конвертиране на обекти. Време е да използвате конфигурацията "Data Conversion 3.0". Вградената помощ за конфигурация описва как да работите. Статиите на уебсайта на ITS също помогнаха.

В резултат на това заредих следните данни в „Преобразуване на данни 3.0“:

• Текстове на общия модул "Диспечер за обмен на данни чрез UniversalFormat" от две бази
• Диаграма на двете основи
• Описание на формата EnterpriseData (от всяка база данни)
• Правила за преобразуване

След изтеглянето отворих правилата за конвертиране на данни, обекти, свойства в "Data Conversion 3.0". Направих промените, от които се нуждаех. След това използвах бутона "Разтоварване на модула за управление на обмена". Текстът на модула е копиран в клипборда. Остава само да го поставите в конфигурацията.

След като експериментирах с настройката на правила в "Data Conversion 3.0", заключих за себе си, че в случай, че направените промени са незначителни, е по-лесно да настроите правила директно в конфигурациите UT и BP, в общия модул "Обмен на данни Мениджър чрез UniversalFormat". Ако редакциите са сериозни, като например добавяне на нов обект в замяна, тогава трябва да използвате конфигурацията " Преобразуване на данни 3.0".

Изпълних задачата да добавя документа "Поръчка към доставчика" към плана за обмен, използвайки " Преобразуване на данни 3.0". В стандартната версия на UT - BP този документ не е включен в плана за обмен.

Нека си припомним, че правилата за регистриране на обекти за разтоварване все още са конфигурирани в конфигурацията "Преобразуване на данни 2.0".

Това са първите впечатления за синхронизиране на данни чрез универсалния формат EnterpriseData.

P.S. Ако имате въпроси и собствени наблюдения относно обмена на данни чрез Универсален формати конфигурация" Преобразуване на данни 3.0", пишете в коментарите. Ще обменим опит.

• Синхронизиране на данни
• Универсален EntepriseData Format
• Преобразуване на данни 3.0
• Преобразуване на данни 2.0
• Управление на търговията
• Счетоводство на предприятието