Виробництво та симуляція торгівлі

Цей посібник призначений для Agent Java SDK v0.3.0 і Java 8+.

Виберіть і режим інтерфейсу, і середовище коштів

Налаштуйте середовище фінансування партнера окремо від зовнішнього режиму торгівлі. Облікові дані для прив’язки та входу є спільними; видача квитка чи токена не вибирає гаманець і не переміщує кошти.

Конфігурація	виробництво	Імітація
Прив’язка та аутентифікація	Спільне прив’язування користувача та одноразові облікові дані	Така сама ідентифікація та автентифікація
Нові перекази та баланси користувачів	Пропустіть `environment` або використовуйте `PRODUCTION`	Явно використовуйте `SIMULATED`
Фінансування відновлення початкового замовлення	Використовуйте збережене оригінальне середовище	Використовуйте збережене оригінальне середовище
Режим торгівлі віджетами	`tradingMode=real`	`tradingMode=demo`
Frontend HTTP/WS target	Виробнича мета надається 6MM	Змодельована мета, надана 6MM
Шість безперервних запитів даних	Виробничі дані	Немає селектора середовища; ці методи не запитують змодельовані дані

Для wallet-transfer-status пропуск environment використовує збережене середовище вихідного замовлення, включаючи змодельоване замовлення. Явно конфліктне середовище відхиляється. Надавайте перевагу зберіганню середовища та його явній передачі під час відновлення операції.

isSimulatedUser описує обліковий запис. Він не направляє нові запити до імітованого гаманця. Пропуск environment у новому запиті на отримання коштів все одно вибирає виробництво, навіть якщо позначка облікового запису має значення true.

Підтримувані Java моделі запитів

Ці запити підтримують withEnvironment(ExecutionEnvironment.SIMULATED):

TransferRequest, TransferAllOutRequest, ReverseOrderRequest.
QueryOrderRequest, ListOrdersRequest.
QueryUserAssetsRequest.
WalletTransferRequest, WalletTransferQueryRequest.

bind, queryAccount, createEntryUrl, createEmbedToken і шість постійних моделей запитів на запити не вибирають середовище коштів.

import com.sixmm.agent.model.ExecutionEnvironment;
import com.sixmm.agent.model.QueryUserAssetsRequest;
import com.sixmm.agent.model.QueryUserAssetsResponse;
QueryUserAssetsResponse assets = client.queryUserAssets(
        QueryUserAssetsRequest.of("1188041528")
                .withFunding()
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Ініціалізуйте client за допомогою Швидкий старт і використовуйте публічний ідентифікатор користувача зі збереженої прив’язки.

Збережіть оригінальне середовище

Зберігайте тип інтерфейсу, agentOrderNo, ідентифікатор користувача та середовище, перш ніж надсилати запит на отримання коштів. Зберігайте це середовище під час запитів статусу, відновлення, узгодження та обробки webhook. Після тайм-ауту ніколи не повторюйте спроби, пропускаючи вихідне середовище або використовуючи новий номер замовлення.

Передача коштів/контрактів залишається в одному середовищі. Імітовані кошти не можуть стати виробничими фондами. Використовуйте окремий змодельований облік на стороні партнера та впізнавані префікси замовлень, наприклад SIM-.

Змодельована послідовність інтеграції

Прив’яжіть користувача та збережіть загальнодоступний ідентифікатор користувача платформи.
Запит балансує з явним SIMULATED і включає Фінансування, коли це необхідно.
Створіть невеликий імітований переказ фінансування та збережіть його початковий бізнес-порядок.
Підтвердьте остаточний результат за допомогою спеціального запиту статусу фінансування.
Відкрийте або вставте цільову сторінку секунд у режимі demo.
Надішліть запит на ті самі імітовані гаманці та звірте фактичну суму переказу.
Щоб протестувати постійну торгівлю, перенесіть імітацію Фінансування в імітацію Контракту та скористайтеся зовнішнім інтерфейсом імітації ф’ючерсів. Шість постійних запитів партнера не можуть перевірити змодельовану історію торгів.

Контрольний лист приймання

Сценарій	Докази для перевірки
Ідентичність	Прив’язане відображення користувача збережено; не можна запитувати користувачів іншого партнера.
Аутентифікація	Потоки перенаправлення та вбудовування використовують нові облікові дані; підписання не створює грошових доручень.
кошти	Обидві сторони узгоджують фактичну суму та остаточний статус.
Невідомий результат	Відновлення використовує оригінальне замовлення без створення другого переказу.
Ізоляція середовища	Змодельовані серверні та зовнішні цілі узгоджуються; виробничі баланси не змінюються.
Запити	Обробляються необхідні фільтри користувачів/категорій, мілісекундні вікна, порожні сторінки та курсори.
Обмеження ставок	Усі виклики запитів спільно використовують регулювальні параметри та повторюють оригінальну невдалу сторінку.
Зберігання	Суми та ідентифікатори залишаються рядками; записи сутностей зберігаються безпосередньо.

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