Загрузка больших файлов через API: как согласовать пределы и продолжение
Загрузка больших файлов через API: как согласовать пределы и продолжение. Паспорт загрузки и четыре отрицательных примера для обсуждения ограниченного этапа разработки.
Короткие практические заметки: вопросы к подрядчику, технические решения и проверки перед запуском.

Загрузка больших файлов через API: как согласовать пределы и продолжение. Паспорт загрузки и четыре отрицательных примера для обсуждения ограниченного этапа разработки.
Пагинация каталога: как избежать пропусков при изменении данных. Таблица вариантов снимка каталога для обсуждения ограниченного этапа разработки.
Подписка на webhook: кто подтверждает адрес и прекращает доставку. Карта жизненного цикла подписки для обсуждения ограниченного этапа разработки.
Справочники между системами: как согласовать коды и переименования. Матрица соответствий двух справочников для обсуждения ограниченного этапа разработки.
Даты в API: как передать момент, срок и локальный день. Словарь временных полей с примерами для обсуждения ограниченного этапа разработки.
Тестовые данные для интеграции: что передать подрядчику без рабочих записей. Паспорт тестового набора обмена для обсуждения ограниченного этапа разработки.
Старый файловый обмен: кодировка, разделители и потерянные символы. Таблица форматов и контрольный файл для обсуждения ограниченного этапа разработки.
Пакетный API: как показать частичный результат по каждой записи. Таблица поэлементного ответа для обсуждения ограниченного этапа разработки.
Единицы измерения в обмене: упаковка, штуки и дробные количества. Карта пересчёта количества для обсуждения ограниченного этапа разработки.
Приглашение сотрудника в B2B-кабинет: кто подтверждает организацию. Схема приглашения с исключениями для обсуждения ограниченного этапа разработки.
Черновик заявки: как сохранить работу пользователя без отправки. Таблица состояний черновика для обсуждения ограниченного этапа разработки.
Документы в кабинете: как сделать таблицы пригодными для чтения. Чек-лист просмотра одного документа для обсуждения ограниченного этапа разработки.
Замещение согласующего в кабинете: срок и границы полномочий. Карта временного замещения для обсуждения ограниченного этапа разработки.
Поиск заявки по номеру клиента: внутренние и внешние идентификаторы. Словарь номеров и сценарии поиска для обсуждения ограниченного этапа разработки.
Массовое скачивание документов: состав архива и ошибки файлов. Описание архива и реестр исключений для обсуждения ограниченного этапа разработки.
Замена вложения к заявке: какая версия отправлена на рассмотрение. Матрица версии вложения и решения для обсуждения ограниченного этапа разработки.
Статусы для клиента: как объяснить внутреннее состояние заявки. Словарь клиентских статусов для обсуждения ограниченного этапа разработки.
Закрытие аккаунта в кабинете: что происходит с открытыми заявками. Карта закрытия и передачи дел для обсуждения ограниченного этапа разработки.
Передача проекта новому подрядчику: что проверить в составе репозитория. Акт состава передаваемого проекта для обсуждения ограниченного этапа разработки.
Проверка восстановления: как выбрать одну учебную аварию. Сценарий восстановления с критериями для обсуждения ограниченного этапа разработки.
Заканчивается поддержка библиотеки: как выбрать порядок замены. Реестр зависимостей с очередностью для обсуждения ограниченного этапа разработки.
Заканчивается место на диске: какие данные можно сокращать. Карта категорий хранения для обсуждения ограниченного этапа разработки.
Окно обслуживания: как объяснить ограничения пользователям. Паспорт окна с текстом для пользователей для обсуждения ограниченного этапа разработки.
Лицензии компонентов: что запросить перед развитием продукта. Реестр компонентов и нерешённых вопросов для обсуждения ограниченного этапа разработки.
Регламентное задание не успевает к утру: как задать границу обработки. Паспорт задания и контрольной точки для обсуждения ограниченного этапа разработки.
Отключение проблемной функции: какие связанные действия проверить. Матрица поведения выключенной функции для обсуждения ограниченного этапа разработки.
Дубли контрагентов: как объединить записи без потери истории. Матрица объединения дублей для обсуждения ограниченного этапа разработки.
Поздние документы в отчёте: когда пересчитывать закрытый период. Политика поздних данных для обсуждения ограниченного этапа разработки.
Excel как рабочий реестр: какие правила перенести в систему. Карта правил одного реестра для обсуждения ограниченного этапа разработки.
Импорт CSV с предварительным просмотром: как объяснить ошибки строки. Макет протокола импорта для обсуждения ограниченного этапа разработки.
Архив рабочих записей: как сохранить поиск и сократить активную базу. Политика архива и возврата для обсуждения ограниченного этапа разработки.
Ручное исправление данных: как сохранить основание и прежнее значение. Карточка ручной корректировки для обсуждения ограниченного этапа разработки.
Суммы и округление: как согласовать расчёт в двух системах. Таблица правил округления для обсуждения ограниченного этапа разработки.
Выгрузка для подрядчика: как исключить лишние персональные поля. Паспорт разрешённой выгрузки для обсуждения ограниченного этапа разработки.
Скан документа: когда нужен OCR и где оставить ручную проверку. Карта поля и проверяемого фрагмента для обсуждения ограниченного этапа разработки.
Помощник передаёт вопрос сотруднику: что должно быть в карточке. Макет карточки передачи для обсуждения ограниченного этапа разработки.
Бюджет запросов к ИИ: как ограничить расходы одного сценария. Модель бюджета с неизвестными параметрами для обсуждения ограниченного этапа разработки.
Новые редакции документов для помощника: как показать актуальность источника. Реестр редакций источников для обсуждения ограниченного этапа разработки.
Зоны исключения на видео: как ограничить анализ лишних областей. Карта зон с условиями пересмотра для обсуждения ограниченного этапа разработки.
Дождь и ночь в видеоаналитике: как собрать проверочные условия. Матрица условий съёмки для обсуждения ограниченного этапа разработки.
Замена камеры: какие параметры повторно проверить для аналитики. Паспорт замены камеры для обсуждения ограниченного этапа разработки.
Отзывы на ответ помощника: как превратить кнопку в полезный разбор. Словарь причин плохого ответа для обсуждения ограниченного этапа разработки.
Рабочие дни в согласовании: как учитывать выходные и разные регионы. Таблица вычисления срока для обсуждения ограниченного этапа разработки.
Отказ в согласовании: как отделить исправление от новой заявки. Карта возврата и повторного согласования для обсуждения ограниченного этапа разработки.
Срок действия предложения в кабинете: что показывать после истечения. Матрица действий по сроку предложения для обсуждения ограниченного этапа разработки.
Запись на услугу: как согласовать доступную ёмкость и лист ожидания. Таблица состояний временного резерва для обсуждения ограниченного этапа разработки.
Заявка с выезда без связи: что сохранять до синхронизации. Карта автономной заявки для обсуждения ограниченного этапа разработки.
Подтверждение выполнения услуги: какие данные нужны для закрытия заявки. Карточка подтверждения услуги для обсуждения ограниченного этапа разработки.
Претензия в кабинете: как связать обращение с выполненной операцией. Карточка претензии с маршрутом для обсуждения ограниченного этапа разработки.
Подключение поставщика к порталу: какой комплект проверить до первого заказа. Карта готовности одного поставщика для обсуждения ограниченного этапа разработки.
ИнтеграцииНовый статус заказа должен дойти до учётной системы, а повторная отправка — не создать второй документ. Начните с правил обмена, а не с выбора транспорта.
Читать материал ↗
ЭксплуатацияПоток одинаковых тревог быстро перестают читать. Полезное уведомление объясняет, какой сценарий пострадал, кто отвечает и с чего начать проверку.
Читать материал ↗
АрхитектураЧто закрепить перед передачей API-модуля: границы, запросы и ответы, ошибки, потребители, проверка совместимости и состав передачи.
Читать материал ↗
ДанныеОдинаковое название показателя не означает одинаковый расчёт. Прежде чем строить новый дашборд, согласуйте определение метрики и источник данных.
Читать материал ↗
ПродуктБот полезен для короткого действия: узнать статус, принять уведомление, заполнить простую заявку. Сложные таблицы и длинные формы удобнее оставить кабинету.
Читать материал ↗
ПроцессыДиаграмма полезна, когда помогает ответить: кто действует, с какими данными и что происходит при исключении. Слишком подробная схема может скрыть эти ответы.
Читать материал ↗
АрхитектураКэш имеет смысл, если известно, какую задержку он сокращает и насколько устаревшие данные допустимы. Иначе ускорение может превратиться в источник расхождений.
Читать материал ↗
ПроцессыИзменения в проекте неизбежны. Проблема начинается, когда новая задача попадает в работу без решения о сроках, стоимости и том, что откладывается.
Читать материал ↗
ЭксплуатацияУспешная сборка ещё не означает безопасный выпуск. Нужно знать, что изменяется в данных, как проверить ключевой сценарий и как действовать при ошибке.
Читать материал ↗
АрхитектураКак разобрать зависший обмен: различить повтор и новое действие, описать состояния, сверку и допустимое восстановление одной операции.
Читать материал ↗
ЭксплуатацияИзменение схемы затрагивает одновременно старую версию приложения, новую версию и накопленные данные. Безопасность зависит от их совместимости.
Читать материал ↗
ДанныеХранилище не исправляет расхождения само по себе. Оно помогает управлять источниками, историей и правилами расчёта, если эти правила определены.
Читать материал ↗
ДанныеЛокальная обработка помогает работать при ограниченной связи, но добавляет задачи по обновлению, хранению и обслуживанию оборудования.
Читать материал ↗
ПроцессыЭлектронный реестр полезен, когда сотрудник понимает, где документ, что от него требуется и кто задерживает следующий шаг. Одной оцифровки формы недостаточно.
Читать материал ↗
ИнтеграцииОчередь помогает разделить системы, но не отменяет договорённостей. Потребителю нужно знать, что означает событие, можно ли его повторить и как оно меняется.
Читать материал ↗
АрхитектураСреднее время ответа может скрывать долгие запросы и неуспешные операции. Начните с пользовательских сценариев, профиля нагрузки и зависимости от внешних систем.
Читать материал ↗
ИнтеграцииЗаказ поступил на сайт, но сотрудник снова вводит его в учётную систему. Статус оплаты есть в одном сервисе, а менеджер проверяет его в другом. Прежде чем заказывать интеграцию, стоит определить, какое действие должно измениться и как вы проверите пользу.
Читать материал ↗
ЭксплуатацияПолезный журнал позволяет восстановить путь конкретной операции. Большой объём сообщений без структуры обычно только увеличивает время поиска.
Читать материал ↗
АрхитектураРазделение приложения на сервисы добавляет независимость, но также сеть, согласованность данных и новые задачи эксплуатации. Решение должно отвечать конкретному ограничению.
Читать материал ↗
ДанныеВысокое качество на подготовленной выборке не гарантирует результата на площадке. Освещение, камеры и сами объекты меняются, поэтому модель требует наблюдения.
Читать материал ↗
ИнтеграцииПокупатель видит один заказ, а внутри него работают несколько систем. Понятная модель состояний помогает не смешивать оплату, резерв, сборку и доставку.
Читать материал ↗
ИнтеграцииПосле перехода на страницу оплаты процесс ещё не закончен. Статус может прийти с задержкой, уведомление — повториться, а клиент — закрыть вкладку.
Читать материал ↗
ПродуктЧисло регистраций само по себе не показывает полезность продукта. Начните с действия, ради которого пользователь приходит, и решения, которое команда хочет принять.
Читать материал ↗
ПродуктДля диалогового продукта полезно видеть не только число сообщений, но и завершённые задачи, ошибки и повторное использование.
Читать материал ↗
ПродуктЗапуск бота — это проверка полного пути пользователя: от первого сообщения до полезного результата. Важны также ограничения и ответы при сбоях.
Читать материал ↗
АрхитектураВ диалоговом сервисе ответ внешней модели может занимать время или завершаться ошибкой. Пользователь должен видеть состояние запроса и понимать следующий шаг.
Читать материал ↗
БезопасностьНазвание роли не описывает все полномочия. Важно указать, какие объекты пользователь видит и какие действия может выполнить над ними.
Читать материал ↗
ПроцессыКак описать приёмку небольшого изменения: исходные условия, действие, ожидаемый результат, ошибки, данные и материалы передачи.
Читать материал ↗
БезопасностьПароли, токены и ключи должны иметь владельца и понятный жизненный цикл. Одного переноса из кода в переменные окружения недостаточно.
Читать материал ↗
БезопасностьАудит эффективнее, когда понятны границы системы, её владельцы и чувствительные данные. Начните с инвентаризации и согласованного объёма проверки.
Читать материал ↗
ЭксплуатацияЗелёный график загрузки сервера не гарантирует, что клиент может оформить заказ. Наблюдение нужно строить вокруг критичных действий.
Читать материал ↗
БезопасностьЕдиный вход упрощает проверку личности, но права внутри приложения и жизненный цикл учётной записи требуют отдельного решения.
Читать материал ↗
ЭксплуатацияЕсли время ограничено, начните с действий, сбой которых останавливает работу или портит данные. Количество тестов само по себе не отражает защищённость процесса.
Читать материал ↗
АрхитектураСистему трудно развивать, но в ней принимают заказы, ведут расчёты и хранят историю. Поэтому вопрос не только в том, на чём написать новую версию, но и в том, как продолжить работу во время изменений.
Читать материал ↗Ничего не найдено. Измените запрос или сбросьте фильтр.
Как выбрать первый сценарий B2B-кабинета: роли клиента, заказы, статусы, документы, источники данных и проверка обмена с 1С.
Читать материал ↗Опишите свою задачу и укажите материал, с которого начали. Обсудим применимость подхода к вашей системе.
