Zur Navigation springen
Agent Java SDK

Produktion und simulierter Handel

Produktion und simulierter Handel: Agent Java SDK v0.3.0-Integration, Beispiele, Parameter und Antwortsemantik.

Als Markdown anzeigen

Dieser Leitfaden richtet sich an Agent Java SDK v0.3.0 und Java 8+.

Wählen Sie sowohl den Frontend-Modus als auch die Fondsumgebung

Konfigurieren Sie die Fondsumgebung des Partner-Backends getrennt vom Frontend-Handelsmodus. Bindungs- und Zugangsdaten werden gemeinsam genutzt; Durch die Ausstellung eines Tickets oder Tokens wird weder eine Wallet ausgewählt noch Geld bewegt.

KonfigurationProduktionSimuliert
Bindung und AuthentifizierungGemeinsame Benutzerbindung und einmalige AnmeldeinformationenGleiche Identität und Authentifizierung
Neue Transfers und BenutzerguthabenLassen Sie environment weg oder verwenden Sie PRODUCTIONVerwenden Sie explizit SIMULATED
Finanzierung der Wiederherstellung der ursprünglichen OrdnungVerwenden Sie die gespeicherte OriginalumgebungVerwenden Sie die gespeicherte Originalumgebung
Widget-HandelsmodustradingMode=realtradingMode=demo
Frontend HTTP/WS-ZielProduktionsziel bereitgestellt von 6MMSimuliertes Ziel bereitgestellt von 6MM
Sechs Perpetual-Data-AbfragenProduktionsdatenKeine Umgebungsauswahl; Diese Methoden fragen keine simulierten Daten ab

Für wallet-transfer-status wird durch Weglassen von environment die gespeicherte Umgebung der ursprünglichen Bestellung verwendet, einschließlich einer simulierten Bestellung. Ein explizit widersprüchliches Umfeld wird abgelehnt. Bevorzugen Sie das Speichern der Umgebung und die explizite Übergabe bei der Wiederherstellung eines Vorgangs.

isSimulatedUser beschreibt das Konto. Neue Anfragen werden nicht an eine simulierte Wallet weitergeleitet. Wenn Sie environment bei einer neuen Geldanforderung weglassen, wird weiterhin die Produktion ausgewählt, selbst wenn die Kontokennzeichnung „true“ ist.

Unterstützte Java-Anfragemodelle

Diese Anfragen unterstützen withEnvironment(ExecutionEnvironment.SIMULATED):

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

bind, queryAccount, createEntryUrl, createEmbedToken und die sechs permanenten Abfrageanforderungsmodelle wählen keine Fondsumgebung aus.

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));

Initialisieren Sie client mit Schnellstart und verwenden Sie die öffentliche Benutzer-ID aus Ihrer gespeicherten Bindung.

Bewahren Sie die ursprüngliche Umgebung

Behalten Sie den Schnittstellentyp agentOrderNo, die Benutzeridentität und die Umgebung bei, bevor Sie eine Geldanforderung senden. Behalten Sie diese Umgebung während Statusabfragen, Wiederherstellung, Abgleich und webhook-Verarbeitung bei. Versuchen Sie es nach einer Zeitüberschreitung niemals erneut, indem Sie die ursprüngliche Umgebung weglassen oder eine neue Bestellnummer verwenden.

Finanzierungs-/Vertragsübertragungen bleiben in einer Umgebung. Scheinfonds können nicht zu Produktionsfonds werden. Verwenden Sie separate, partnerseitig simulierte Abrechnungen und erkennbare Bestellpräfixe wie SIM-.

Simulierte Integrationssequenz

  1. Binden Sie den Benutzer und speichern Sie die Benutzer-ID der öffentlichen Plattform.
  2. Fragen Sie Salden mit explizitem SIMULATED ab und schließen Sie bei Bedarf die Finanzierung ein.
  3. Erstellen Sie eine kleine simulierte Finanzierungsübertragung und behalten Sie den ursprünglichen Geschäftsauftrag bei.
  4. Bestätigen Sie das Endergebnis mit der speziellen Abfrage zum Finanzierungsstatus.
  5. Öffnen oder betten Sie die Zielsekundenseite im Modus demo ein.
  6. Fragen Sie dieselben simulierten Wallets ab und gleichen Sie den tatsächlich übertragenen Betrag ab.
  7. Um den ewigen Handel zu testen, übertragen Sie die simulierte Finanzierung auf den simulierten Vertrag und verwenden Sie das simulierte Futures-Frontend. Die sechs ständigen Partnerabfragen können den simulierten Handelsverlauf nicht validieren.

Checkliste für die Abnahme

SzenarioBeweise zur Überprüfung
IdentitätDie gebundene Benutzerzuordnung wird gespeichert; Benutzer anderer Partner können nicht abgefragt werden.
AuthentifizierungUmleitungs- und Einbettungsflüsse verwenden neue Anmeldeinformationen. Durch die Unterzeichnung werden keine Zahlungsaufträge erstellt.
MittelÜber den tatsächlichen Betrag und den Endstatus einigen sich beide Seiten.
Unbekanntes ErgebnisBei der Wiederherstellung wird die ursprüngliche Bestellung verwendet, ohne dass eine zweite Überweisung erstellt wird.
UmgebungsisolationSimulierte Backend- und Frontend-Ziele stimmen überein; Produktionsbilanzen bleiben davon unberührt.
AbfragenErforderliche Benutzer-/Kategoriefilter, Millisekundenfenster, leere Seiten und Cursor werden behandelt.
TarifbegrenzungenAlle Abfrageaufrufer teilen sich die Drosselung und versuchen erneut, die ursprünglich fehlgeschlagene Seite aufzurufen.
LagerungBeträge und IDs bleiben Zeichenfolgen; Entitätsdatensätze werden idempotent gespeichert.

Ändern Sie vor dem Wechsel zur Produktion sowohl das Backend-Fondsziel als auch den Frontend-Modus. Ausstehende Aufträge erholen sich weiterhin in ihrem ursprünglichen Umfeld.

Quelle und zugehörige Leitfäden