Vai alla navigazione
Agent Java SDK

Produzione e trading simulato

Produzione e trading simulato: Agent Java SDK Integrazione v0.3.0, esempi, parametri e semantica della risposta.

Visualizza come Markdown

Questa guida è rivolta a Agent Java SDK v0.3.0 e Java 8+.

Scegli sia la modalità frontend che l’ambiente dei fondi

Configura l’ambiente dei fondi del backend del partner separatamente dalla modalità di trading del frontend. Le credenziali di vincolo e di ingresso sono condivise; L’emissione di un biglietto o di un token non seleziona un portafoglio né sposta fondi.

ConfigurazioneProduzioneSimulato
Vincolo e autenticazioneAssociazione utente condivisa e credenziali monousoStessa identità e autenticazione
Nuovi trasferimenti e saldi utenteOmettere environment o utilizzare PRODUCTIONUtilizza esplicitamente SIMULATED
Finanziamento del recupero dell’ordine originaleUtilizza l’ambiente originale salvatoUtilizza l’ambiente originale salvato
Modalità di scambio dei widgettradingMode=realtradingMode=demo
Frontend HTTP/Destinazione WSObiettivo di produzione fornito da 6MMBersaglio simulato fornito da 6MM
Sei query di dati perpetuiDati di produzioneNessun selettore di ambiente; questi metodi non interrogano i dati simulati

Per wallet-transfer-status, l’omissione di environment utilizza l’ambiente salvato dell’ordine originale, incluso un ordine simulato. Un ambiente esplicitamente conflittuale viene rifiutato. È preferibile archiviare l’ambiente e trasmetterlo esplicitamente durante il ripristino di un’operazione.

isSimulatedUser descrive l’account. Non instrada nuove richieste a un portafoglio simulato. Omettendo environment su una nuova richiesta di fondi si seleziona comunque la produzione, anche quando il flag dell’account è vero.

Modelli di richiesta Java supportati

Queste richieste supportano withEnvironment(ExecutionEnvironment.SIMULATED):

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

bind, queryAccount, createEntryUrl, createEmbedToken e i sei modelli di richiesta di query perpetua non selezionano un ambiente di fondi.

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

Inizializza client utilizzando Avvio rapido e utilizzare l’ID utente pubblico dall’associazione salvata.

Preservare l’ambiente originale

Mantieni il tipo di interfaccia, agentOrderNo, l’identità dell’utente e l’ambiente prima di inviare una richiesta di fondi. Mantieni tale ambiente durante le query sullo stato, il ripristino, la riconciliazione e l’elaborazione webhook. Dopo un timeout, non riprovare mai omettendo l’ambiente originale o utilizzando un nuovo numero d’ordine.

I trasferimenti di finanziamenti/contratti rimangono all’interno di un unico ambiente. I fondi simulati non possono diventare fondi di produzione. Utilizza contabilità simulata separata lato partner e prefissi di ordine riconoscibili come SIM-.

Sequenza di integrazione simulata

  1. Associa l’utente e salva l’ID utente della piattaforma pubblica.
  2. Richiedi i saldi con SIMULATED esplicito e includi i finanziamenti quando necessario.
  3. Crea un piccolo trasferimento di fondi simulato e mantieni il suo ordine commerciale originale.
  4. Conferma il risultato finale con la query dedicata sullo stato dei finanziamenti.
  5. Apri o incorpora la pagina dei secondi di destinazione in modalità demo.
  6. Interroga gli stessi portafogli simulati e riconcilia l’importo effettivamente trasferito.
  7. Per testare il trading perpetuo, trasferisci i finanziamenti simulati al contratto simulato e utilizza il frontend dei futures simulati. Le sei query perpetue dei partner non possono convalidare la cronologia di trading simulata.

Lista di controllo per l’accettazione

ScenarioProve da verificare
IdentitàLa mappatura degli utenti associati viene salvata; non è possibile interrogare gli utenti di un altro partner.
AutenticazioneI flussi di reindirizzamento e incorporamento utilizzano nuove credenziali; la firma non crea ordini di fondi.
FondiEntrambe le parti concordano sull’importo effettivo e sullo stato finale.
Risultato sconosciutoIl recupero utilizza l’ordine originale senza creare un secondo trasferimento.
Isolamento dell’ambienteGli obiettivi simulati di backend e frontend concordano; gli equilibri produttivi restano inalterati.
DomandeVengono gestiti i filtri utente/categoria richiesti, le finestre di millisecondi, le pagine vuote e i cursori.
Limiti di tariffaTutti i chiamanti della query condividono la limitazione e riprovano la pagina originale con errori.
MagazzinaggioGli importi e gli ID rimangono stringhe; i record dell’entità vengono salvati in modo idempotente.

Prima di passare alla produzione, modifica sia il target dei fondi di backend che la modalità di frontend. Gli ordini pendenti continuano a riprendersi nel loro ambiente originale.

Fonte e guide correlate