ax3,ax4,ax2009,ax2012: RunBaseBatch: как правильно добавить действия, которые должны быть выполнены на клиенте? например, импорт из Excel.

[Raven Melancholic]

В одной пакетной задаче (BatchJob), по крайней мере, в DAX2009 смешивание для разных Batch этой задачи режимов выполнения (поле RunType таблицы Batch) работало - нужные задания выполнялись пакетником, встроенным в AOS, нужные - запущенной формой я-ля до DAX4 включительно.
Но это не решает условия:

Цитата:

Ровно как это написано в вопросе.

• должны быть выполнены на клиенте из-за аппаратных ЭЦП, какого-нибудь ХАСПа или подобные системы "безопасности" и "шифрования".
• должны быть выполнены на клиенте потому что там стоит драйвер камеры, с которой надо принять вход или счетчик посетителей или пос-терминалы с которых аксапта получает Z-отчеты или еще какое-нибудь оборудование.
• должны быть выполнены на клиенте, поскольку только на этой машине установлен дорогуще-лицензионный кодек чего-нибудь во что-нибудь.

Ведь этот legacy запускается не на машине клиента, а на отдельной выделенной машине и, как заметил belugin, её окружение совсем другое и там может не быть дорогуще-лицензионный кодека.
Похоже, что обе части сделать полностью на пакетной обработке не получится. Даже если legacy и будет выполнять клиентский класс (кстати, он может выполнять и серверный), то это совсем не тот клиент, на котором началось всё это безобразие.
Пока наиболее подходящим, на мой взгляд, является подход, который предложил Владимир Максимов - что можно, делаем на клиенте без пакета, обычным RunBase, а для последующей обработки программно из него формируем пакетную задачу. Да, в этом случае, пользователю придется ждать выполнения клиентской части на своей машине (но диалог будет закрыт и вполне можно выводить прогресс-бар, чтобы было не скучно).

[Weez]

Цитата:

Сообщение от Raven Melancholic

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

А можно и в thread все обернуть, если задача позволяет. Тогда и ждать ничего не придется.

[S.Kuskov]

Цитата:

Сообщение от mazzy

Как и куда правильно вставить действия, которые должны выполняться на клиенте?

Мне кажется нужно рассмотреть как минимум два случая. В зависимости от ситуации правильным может оказаться и тот и другой.

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

В первом случае, архитектурно всё просто. Синхронно, т.е. последовательно, выполняем требуемые действия на стороне клиента, после чего стандартными средствами реализуем добавление пакетного задания в очередь. Выполняется всё в основном потоке, используется стандартное клиент-серверное взаимодействие для сохранения необходимых параметров пакетного задания в базе данных. Можно обсуждать что, как и куда сохранять.

- если второе, то получается, что это должен быть уже не обычный клиентский процесс аксапты, а некий специализированный (специально выделенный и настроенный) процесс, ответственный за предоставление некого сервиса. Т.е. уже не он передаёт данные, а у него их запрашивают. Вообще говоря это происходит асинхронно относительно процесса разместившего задание на сервере пакетов! И тут клиент(аксапты) уже и не в роли клиента(архитектурно) выступает.

Наверное чтобы дальше обсуждать более конкретно нужно хотя бы из этих двух вариантов выбор сделать.

[mazzy]

Цитата:

Сообщение от S.Kuskov

Наверное чтобы дальше обсуждать более конкретно нужно хотя бы из этих двух вариантов выбор сделать.

зачем делать выбор? почему логика или-или?
разве не может быть некоего переключателя в этом нечто?
тогда будет что-то вроде методов showQuery, canRunInBatch...

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

возвращаясь к исходному вопросу:
если мы говорим о друх классах, то клиентский скорее всего нужно выполнить сразу, а серверный по расписанию. Но параметры расписания передаются в первый класс (в клиентский). Нужно еще как то передать расписание серверному классу.

если мы говорим об одном классе (какой-то расширенный runBaseBatch), то как правильно расширить его функционал?

[Владимир Максимов]

Мда... Когда я читал вопрос, мне даже в голову не могло прийти, что речь идет именно о пакетной обработке на стороне клиента. Ну, RunBaseBacth, ну и что? Но пакетник на клиенте - глупо и бессмысленно.

Похоже, здесь ловушка "программизма", как ни странно. Чисто программистский подход без учета самой задачи, которую надо сделать. Если отвлечься от кода, то постановка задачи заключается в следующем

1. Организовать диалог с пользователем
2. Загрузить данные с одного конкретного клиента. Важно! Только один клиент из всех установленных!
3. Выполнить обработку полученных данных

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

Ну, само-то пакетное задание создается на клиенте. Этот самый диалог с пользователем. Но, вот мы его создали. А дальше?

Запустили мы пакетную обработку на AOS. Нам надо запустить обработку на клиенте.

Вопросы:

- Как, каким образом, AOS узнает о том, на каком именно клиенте надо запустить обработку?
- Как, каким образом, AOS может запустить обработку именно на нужном клиенте? Как он сможет передать управление этому самому клиенту?

Вот если Вы сможете найти ответы на эти вопросы, тогда и станет понятно, как модифицировать RunBaseBacth и стоит ли это вообще делать

Единственное, что мне приходит в голову, для передачи управления - это Buisness Connector. Но к модификации RunBaseBatch это отношения не имеет

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Мда... Когда я читал вопрос, мне даже в голову не могло прийти, что речь идет именно о пакетной обработке на стороне клиента.

скажу по секрету, когда писал вопрос мне пакетник на клиенте тоже в голову не приходил. также я полностью забыл про runsImpersonated.

Цитата:

Сообщение от Владимир Максимов

Но пакетник на клиенте - глупо и бессмысленно.

согласен.
но у нас действительно есть runsImpersonated.
после небольшого копания с ним, я не думаю, что runsImpersonated это правильный способ.

Цитата:

Сообщение от Владимир Максимов

Похоже, здесь ловушка "программизма", как ни странно. Чисто программистский подход без учета самой задачи, которую надо сделать. Если отвлечься от кода, то постановка задачи заключается в следующем

возможно.

Цитата:

Сообщение от Владимир Максимов

1. Организовать диалог с пользователем
2. Загрузить данные с одного конкретного клиента. Важно! Только один клиент из всех установленных!
3. Выполнить обработку полученных данных

тут важно понимать, что пользователь может быть роботом.
и для робота бессмысленно организовывать диалог в виде GUI-окна с кнопками Ok/Cancel и прочими GUI-контролами.

если под "диалогом" понимается некий интерфейс и обмен данными без привязки к GUI - полностью согласен.

Собственно поэтому в исходном вопросе нет ни пользователя, ни средств общения с ним.
В данной задаче предполагается, что входящие параметры как-то получены на клиенте.
Да, в данной ветке хотелось бы обсудить шаг 2,3

Цитата:

Сообщение от Владимир Максимов

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

да. и не просто длительная время, а может завершиться ошибками. и вообще имеет свой протокол взаимодействия с пользователем (в широком смысле слова).

Цитата:

Сообщение от Владимир Максимов

Ну, само-то пакетное задание создается на клиенте. Этот самый диалог с пользователем. Но, вот мы его создали. А дальше?

или через Business Connector.
Да, скорее всего инициатором будет не AOS. (хотелось бы рассмотреть именно этот вариант)
Но не вижу причин запрещать AOSу быть инициатором. (этот вариант готов пропустить в этой ветке обсуждения)

Цитата:

Сообщение от Владимир Максимов

Запустили мы пакетную обработку на AOS. Нам надо запустить обработку на клиенте.

Если честно, я ожидал способ когда клиентские действия выполняются ДО создания пакетной обработки. Обращаю внимание, до СОЗДАНИЯ.

Но раз появился runsImpersonated, то готов послушать про вариант "клиентские действия после запуска пакетной обработки на AOS". Мне этот способ не нравится, но вдруг я чего не понимаю.

Цитата:

Сообщение от Владимир Максимов

- Как, каким образом, AOS узнает о том, на каком именно клиенте надо запустить обработку?
- Как, каким образом, AOS может запустить обработку именно на нужном клиенте? Как он сможет передать управление этому самому клиенту?

понятия не имею.
Эти вопросы появились после того, как ax_mct начал утверждать что runsImpersonated - правильный способ.
В исходном вопросе таких требований не было.

Цитата:

Сообщение от Владимир Максимов

Вот если Вы сможете найти ответы на эти вопросы, тогда и станет понятно, как модифицировать RunBaseBacth и стоит ли это вообще делать

Если честно, то совершенно не планировал искать ответы на эти вопросы.
Я думал, что можно остаться в существующей парадигме RunBaseBatch, и только добавить действия, которые должны быть выполнены на клиенте.

собственно исходный вопрос так и составлен:

Цитата:

Сообщение от mazzy

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

Как и куда правильно вставить действия, которые должны выполняться на клиенте?

[Raven Melancholic]

Цитата:

Если честно, я ожидал способ когда клиентские действия выполняются ДО создания пакетной обработки. Обращаю внимание, до СОЗДАНИЯ.

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

• Серверный пакет забирает у партнера данные (ftp, WEB вервис и т.п., не суть) - работаем на сервере.
• Серверный пакет на основе этих данных выполняет какой-то расчет - работаем на сервере.
• Результаты расчета предлагаются ответственному лицу, чтобы он проверил их и применил электронную подпись (может быть очень важно, что этот этап на совершенно конкретном ПК должен выполняться) - работаем на клиенте.
• Серверный пакет подписанные данные отправляет партнеру.

То есть, явная смесь клиент-серверной обработки, причем инициатор не конкретный пользователь.

[mazzy]

Цитата:

Сообщение от Raven Melancholic

То есть, явная смесь клиент-серверной обработки

Не, нету тут смеси.

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

если данные приняты в рамках какого-то импорта, а импорт ожидает call back, то при первом импорте неизбежно появится какой то тикет/идентификатор сессии. на последнем шаге этот тикет надо будет отдать обратно.

процесс хорошо и логично разбивается на несколько классов, которые обрабатывают SQL-данные традиционным образом.

========
в исходном вопросе в этой ветке предполагалось, что идентификатор пакетного задания и будет таким тикетом.

[S.Kuskov]

Цитата:

Сообщение от Raven Melancholic

Результаты расчета предлагаются ответственному лицу, чтобы он проверил их и применил электронную подпись (может быть очень важно, что этот этап на совершенно конкретном ПК должен выполняться) - работаем на клиенте

Мне кажется что такая обработка на клиенте ну уже никак не должна являться частью пакетного задания. В том смысле что ответственность за её выполнение не должен нести сервер пакетов. Сервер пакетов должен поставить выполнение этой задачи на паузу, возможно бросить какое-то событие куда-то, и ждать пока в рамках этой задачи откуда-то не возникнет входящего события с входными данными для дальнейшей их обработки.
Может ли при такой организации клиент иметь доступ к серверному экземпляру задачи и управлять им? - Конечно может
Должен ли сервер управлять действиями клиента? - Я считаю, что нет. Разные могут быть ситуации, но всегда инициатором клиент серверного взаимодействия должен быть клиент. Иначе это уже не клиент-серверное взаимодействие

[ax_mct]

RunBaseBatch.runsImpersonated Method [AX 2012]
https://docs.microsoft.com/en-us/pre...822697(v=ax.60)

Глянул в AX2012R3
class rPayBalanceSheetPrint extends OXMLExcelReport_RPay
использует runsImpersonated и запускается на клиенте

То есть способ как бы стандартный но как правильно отмечено выше несмотря на то что это RunBaseBatch о серверной пакетном исполнении речи быть здесь не может.

Такие клиентские RunBaseBatch это либо прямой запуск без расписания либо как полагаю по расписанию на выделенной клиентской машине. Пакетный "сервер" c клиентcкой OS и клиентом AX имеет право быть.

При этом этот же клиентский RunBaseBatch может без всяких хитростей запускать серверный код.

[ax_mct]

Цитата:

Сообщение от mazzy

процесс хорошо и логично разбивается на несколько классов, которые обрабатывают SQL-данные традиционным образом.

========
в исходном вопросе в этой ветке предполагалось, что идентификатор пакетного задания и будет таким тикетом.

Цитата:

смесь клиент-серверной обработки

В принципе если процесс разделяем то не обязательно клиентскому процессу и серверному (как потоку исполнения) быть связанными. Они могут независимо обрабатывать SQL таблицы которые меняют свой статус обработки. Если утрировать то Status:ReadyForClient, Status:ReadyForServer etc

[mazzy]

Цитата:

Сообщение от ax_mct

Глянул в AX2012R3
class rPayBalanceSheetPrint extends OXMLExcelReport_RPay
использует runsImpersonated и запускается на клиенте

погляжу, спасибо за наводку.

Цитата:

Сообщение от ax_mct

...

При этом этот же клиентский RunBaseBatch может без всяких хитростей запускать серверный код.

Конечно да. Но это не ответ на исходный вопрос.
Исходный вопрос повторить?

Цитата:

Сообщение от mazzy

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

Как и куда правильно вставить действия, которые должны выполняться на клиенте?

[ax_mct]

Цитата:

Сообщение от mazzy

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

Как и куда правильно вставить действия, которые должны выполняться на клиенте?

Не хватает workflow для понимания взаимодействия клиента и сервера
Например
Шаг 1. диалог на клиенте, результат работы которого доступность файла или данных для серверного пакетника.
Шаг 2. Обработка данных или файла на сервере требующая работы кода на клиенте.
Шаг 3. Выполнение неких действий на клиенте

Подразумеваемые действия на каком шаге если данная схема корректна?

[belugin]

Цитата:

Сообщение от ax_mct

Не хватает workflow для понимания взаимодействия клиента и сервера

Насколько я понял Маззи хочет чтобы мы рассмотрели все возможные требования и все возможные варианты дизайна. Подобно тому, как F# если в функцию передать недостаточное количество параметров, возвращает функцию от оставшихся, а не пишет ошибку. Это называется карринг.

Я думаю в такой постановке это очень сложно, надо учесть что бывают разные объемы файлов, разные категории пользователей, разные причины почему что-то надо делать на клиенте, разный временной бюджет. Утрируя: Одно дело когда ты программист сидящий у вендора и тебе через год надо решение для того, чтобы миллионы начинающих пользователей загружали терабайтные фильмы желательно с минимальной нагрузкой на поддержку c докачкой и тротлингом администрируемым из веб-админки.

Другое дело, когда ты бородатый сиадмин Вася сидящий на клиенте и тебе рз в месяц надо загрузит 3Кб excel файл на одном компе, причем единственный пользователь - ты сам

[mazzy]

Цитата:

Сообщение от ax_mct

Не хватает workflow для понимания взаимодействия клиента и сервера

кому не хватает?

Цитата:

Сообщение от ax_mct

Подразумеваемые действия на каком шаге если данная схема корректна?

в этом и есть исходный вопрос

Цитата:

Сообщение от belugin

Насколько я понял Маззи хочет чтобы мы рассмотрели все возможные требования и все возможные варианты дизайна.

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

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

Цитата:

Сообщение от belugin

Подобно тому, как F# если в функцию передать недостаточное количество параметров, возвращает функцию от оставшихся, а не пишет ошибку. Это называется карринг.

можно и так.

Цитата:

Сообщение от belugin

Я думаю в такой постановке это очень сложно

в какой постановке? рассматреть ВСЕ возможные требования? конечно очень сложно.
поэтому я сформулировал "действия, которые должны быть выполнены на клиенте".
причины "почему действия должны быть выполнены на клиенте" не важны, на мой взгляд.
Но если хочется - рассмотрите, конечно. расскажите какие требования и как могут изменить мою формулировку.

Цитата:

Сообщение от belugin

надо учесть что бывают разные объемы файлов

канешно!
а также пустой и несуществующий файл.

Цитата:

Сообщение от belugin

разные категории пользователей

?! зачем?
конечно можно рассматривать и это. но, как я уже говорил, достаточно считать что данные от пользователя уже получены.
опять же - см. исходную формулировку вопроса.

и снова и снова: ни в коем случае не хочу запрещать обсуждение вопроса диалога с разными категориями пользователей. это очень интересный вопрос. но его лучше обсуждать в отдельной ветке.

Цитата:

Сообщение от belugin

разные причины почему что-то надо делать на клиенте, разный временной бюджет.

зачем? ты о real time системах? на java?

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

Цитата:

Сообщение от belugin

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

и? как это поможет обсуждению среди профессионалов на публичном форуме?!

извини, когда я создавал эту ветку, то не предполагал как-то помочь программистам, сидящим у вендора.

Цитата:

Сообщение от belugin

Другое дело, когда ты бородатый сиадмин Вася сидящий на клиенте и тебе рз в месяц надо загрузит 3Кб excel файл на одном компе, причем единственный пользователь - ты сам

Даже если сделать такое предположение, то ответ на исходный вопрос то какой?

[ax_mct]

Цитата:

Сообщение от mazzy

Originally Posted by ax_mct
>>Подразумеваемые действия на каком шаге если данная схема корректна?

в этом и есть исходный вопрос

Цитата:

Шаг 1. диалог на клиенте, результат работы которого доступность файла или данных для серверного пакетника.
Шаг 2. Обработка данных или файла на сервере требующая работы кода на клиенте.
Шаг 3. Выполнение неких действий на клиенте

Ответ очевиден что feasible только шаг 1.
Какая бы тяжелая обработка ни была, конвертация файла который может быть прочитан только на клиенте, из, к примеру .xslx или .dat, в читаемый для сервера вид (json, xml, запись в DB) не займет неприемлимое время.

Где именно разместить данный код в RunBaseBatch дело десятое и во время кодирования очевидное.
Пусть будет getFromDialog (хотя я не держу в голове что там и где до тех пор пока не начинаю кодировать).

Если очень хочется UX то можно там же на клиенте вызывать асинхронный код который принимает некий Ref и занимается трансформацией данных в читабельное для сервера . RunBaseBatch на сервере этот Ref использует во время пакетного запуска.

Я обычно очень мучаюсь при выборе оптимального решения но вот здесь вариантов то в принципе и нет. То есть они есть но при возможности все делать на Шаг 1 рассматривать awkward варианты просто не смысла. Правильно то что стандартно для приложения/фрэймворка. В нашем случае у нас просто расширенный случай getFromDialog.

[belugin]

Цитата:

Сообщение от mazzy

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

Я тогда не понял тебе подходит ответ, который "правильный" для хотя бы одной ситуации, подпадающей под твой вопрос? Изначально был пример импорта из excel, так как мы знаем, что в ax2012 у нас есть OOXML, то можно импорт из excel выполнить на сервере а "действия, которые необходимо сделать на клиенте" - это прочитать этот файл и загрузить на сервер.

Тут возникает вопрос, почему именно, надо делать на пакетном сервере. Если, чтобы сделать расписание (в полночь, когда никто не работает, должны ездить фуры и загружать наш пакетный сервер) то логично его настроить один раз и не давать менять простым пользователям. Соответственно это должно быть одно пакетное задание с одним расписанием которое будет просыпаться, читать из очереди файлы и импортировать (для распараллеливания использовать таски). А простые пользователи пользуются отдельным интерфейсом, чтобы положить файлы в очередь и утром дождаться уведомления. Этот интерфейс должен быть отдельным ранбейзом или формой (или просто сетевой папкой). Как-то так. У другого сценария - другие решения.

Цитата:

причины "почему действия должны быть выполнены на клиенте" не важны, на мой взгляд.

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

Цитата:

Но если хочется - рассмотрите, конечно. расскажите какие требования и как могут изменить мою формулировку.

Вот про это я писал. Надо либо выдумывать все сценарии из головы, либо угадать тот сценарий, который ты неявно имеешь ввиду либо делиться опытом по тем сценариями с которыми мы имели дело.

Цитата:

канешно!
а также пустой и несуществующий файл.

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

Цитата:

и снова и снова: ни в коем случае не хочу запрещать обсуждение вопроса диалога с разными категориями пользователей. это очень интересный вопрос. но его лучше обсуждать в отдельной ветке.

У тебя к первому моему решению сразу же появилась претензия именно к UX.

Цитата:

зачем? ты о real time системах? на java?

Имелось ввиду время на разработку.

Цитата:

и? как это поможет обсуждению среди профессионалов на публичном форуме?!

извини, когда я создавал эту ветку, то не предполагал как-то помочь программистам, сидящим у вендора.

Я просто привел два экстремума по клиентской базе чтобы обозначить диапазон.

Цитата:

Даже если сделать такое предположение, то ответ на исходный вопрос то какой?

Если единственный пользователь сисадмин Вася, решение надо срочно, я бы вставил выкачку файла в getFromDialog: сисадмин Вася единственный в мире потребитель нашего решения и мы с ним договорились что ему надо получить работающий код как можно быстрее, он зависшего диалога не испугается а просто посмотрит, что resmon показывает ax32 читающий myfile.xlsx.

Мое глубокое убеждение, что любой дизайн есть продукт компромиссов. Что именно приносить в жертву чему - зависит от конкретных требований. Если требования описаны недостаточно полно, пробелы заполнятся исходя из того, что тот, кто интерпретирует требования посчитает наиболее вероятным.

P.S. На практике до Dyn365FO я чаще всего встречался с кодом, который не читал с клиента файл, а просто надеялся, что пользователь введет путь к сетевой папке. Т.е. задачу старались обойти. В одном месте видел свой специализированный мультитредный сервер закачек, когда я спросил, почему не воспользовались сетевой папкой, ответили, что не хотят администрировать доступ к общей папке.