Localizzare gli User Defined ObjectsGli UDO sono componenti configurabili in JD Edwards, come estensioni di modulo, pagine, watchlist e query, che gli utenti creano senza modificare il codice di base. in JD Edwards EnterpriseOne è sempre stato un compito manuale faticoso: qualcuno con competenze linguistiche deve aprire ogni UDO, tradurre i titoli e le etichette stringa per stringa e ripetere il processo per ogni lingua di destinazione. Con il servizio OCI Language AI e il JD Edwards OrchestratorUno strumento integrato di JD Edwards che consente di progettare flussi di lavoro automatizzati collegando EnterpriseOne a servizi REST esterni senza scrivere codice personalizzato., ora è possibile automatizzare l'intera pipeline di traduzione, trasformando ore di lavoro noioso in una singola chiamata di orchestrazione.

Come tradurre le stringhe degli UDO di JD Edwards utilizzando OCI Language AI

Perché la traduzione manuale degli UDO è un problema?

JD Edwards EnterpriseOne supporta un ricco ecosistema di UDO: query, formati di griglia, estensioni di modulo, pagine composte, watchlist e altro ancora. Ognuno di questi oggetti contiene stringhe rivolte all'utente: titoli, descrizioni, intestazioni di colonna ed etichette. Quando l'organizzazione opera in più paesi, ognuna di queste stringhe necessita di una versione tradotta per ogni lingua supportata.

Tradizionalmente, ciò significa che un traduttore umano (o un utente esperto bilingue) deve inserire manualmente ogni traduzione tramite l'interfaccia di EnterpriseOne. Il processo è lento, soggetto a errori e non scalabile. Se si aggiunge una nuova lingua o si crea un lotto di nuovi UDO, l'arretrato delle traduzioni cresce immediatamente. Peggio ancora, si insinuano incongruenze perché persone diverse traducono gli stessi termini in modo differente tra i vari oggetti.

Cos'è OCI Language AI e cosa può fare?

L'OCI Language ServiceUn servizio AI serverless su Oracle Cloud Infrastructure che fornisce modelli pre-addestrati per l'analisi del testo, tra cui traduzione, analisi del sentiment e riconoscimento delle entità. è un servizio AI pre-addestrato e serverless disponibile su Oracle Cloud Infrastructure. Tra le sue funzionalità, quella che conta in questo contesto è l'API di traduzione batch (batchLanguageTranslation). Accetta fino a 100 documenti di testo per chiamata, rileva automaticamente la lingua di origine e li traduce nella lingua di destinazione scelta. Copre più di 30 lingue e, poiché utilizza modelli di traduzione automatica neurale, la qualità dell'output è significativamente migliore rispetto ai sistemi basati su regole.

L'API è un semplice endpoint RESTRepresentational State Transfer — uno stile di architettura web standard in cui i client inviano richieste HTTP (GET, POST, ecc.) a endpoint del server che restituiscono dati, solitamente in formato JSON.. Si invia (POST) un payload JSON contenente i documenti e il codice della lingua di destinazione, e si riceve una risposta JSON con il testo tradotto. Ci sono alcuni vincoli da tenere presenti: ogni documento deve essere inferiore a 5.000 caratteri e il batch totale non può superare i 20,000 caratteri. Per le tipiche stringhe UDO — titoli brevi e descrizioni — raramente ci si avvicina a questi limiti.

Come funziona l'architettura di integrazione?

L'integrazione segue un modello lineare che sfrutta il framework esistente di JD Edwards Orchestrator. Ecco il flusso di alto livello:

1. Autenticazione: L'orchestrazione si autentica su OCI utilizzando la firma basata su chiavi API. JD Edwards fornisce già percorsi di apprendimento per configurare l'autenticazione OCI tramite un soft coding recordUn record di configurazione in JD Edwards che memorizza i dettagli di connessione (come URL, credenziali e intestazioni) per le chiamate ai servizi REST esterni, evitando valori codificati nel codice. nella configurazione della connessione dell'Orchestrator.
2. Estrazione delle stringhe UDO: L'orchestrazione legge i metadati degli UDO dalle relative tabelle di EnterpriseOne (come la F952400 per le pagine, la F952439 per le estensioni di modulo o la F952420 per le watchlist) e raccoglie le stringhe che necessitano di traduzione.
3. Chiamata all'API OCI Language: L'orchestrazione invia una richiesta POST all'endpoint batchLanguageTranslation con le stringhe raccolte e il codice della lingua di destinazione desiderato.
4. Scrittura delle traduzioni: L'orchestrazione analizza la risposta dell'API e scrive le stringhe tradotte nei corrispondenti record UDO in EnterpriseOne.

Poiché l'Orchestrator gestisce le chiamate REST in modo nativo, non è necessario alcun codice personalizzato, middleware o strumento di integrazione di terze parti. L'intero flusso di lavoro viene configurato tramite Orchestrator Studio.

Come si imposta la connessione OCI in Orchestrator?

Prima di chiamare l'API Language, è necessaria una connessione funzionante tra JD Edwards e OCI. Questo comporta tre passaggi:

In primo luogo, crea una coppia di chiavi APIUna combinazione di chiave pubblica/privata utilizzata per firmare le richieste REST verso Oracle Cloud Infrastructure. La chiave pubblica viene caricata sul tuo profilo utente OCI; la chiave privata rimane sul tuo server. nella tua tenancy OCI e carica la chiave pubblica sul tuo profilo utente OCI. In secondo luogo, configura un record di soft coding nella configurazione della connessione Orchestrator con l'URL dell'endpoint REST per il servizio Language (ad esempio, https://language.aiservice.<region>.oci.oraclecloud.com). In terzo luogo, imposta gli header per la firma della richiesta — OCI utilizza uno schema di autenticazione basato su firma in cui ogni richiesta deve includere un header di autorizzazione firmato. La documentazione di JD Edwards fornisce istruzioni passo-passo a riguardo nel percorso di apprendimento "Authentication for Oracle Cloud Infrastructure Services".

Come si presenta la richiesta all'API di traduzione?

Il payload inviato all'endpoint OCI Language è una struttura JSON lineare. Ecco un esempio semplificato che mostra come il titolo di un UDO potrebbe essere tradotto dall'inglese al francese:

{
  "documents": [
    {
      "key": "udo-title-001",
      "text": "Open Purchase Orders by Supplier",
      "languageCode": "en"
    },
    {
      "key": "udo-title-002",
      "text": "Weekly Sales Summary",
      "languageCode": "en"
    }
  ],
  "targetLanguageCode": "fr",
  "compartmentId": "ocid1.compartment.oc1..example"
}

La risposta restituisce ogni documento con il relativo testo tradotto, la lingua di origine rilevata e la lingua di destinazione. La tua orchestrazione mappa quindi ogni key al corrispondente record UDO e salva la traduzione.

Puoi anche impostare languageCode su "auto" e lasciare che l'API rilevi la lingua di origine, il che è utile quando le stringhe degli UDO sono già in un mix di lingue diverse.

Quali sono i vantaggi pratici di questo approccio?

Il vantaggio più evidente è la velocità. Ciò che prima richiedeva ore di inserimento manuale dei dati ora può essere eseguito in pochi secondi. Una singola orchestrazione può iterare su tutti gli UDO non tradotti, raggruppare le stringhe in batch, chiamare l'API e scrivere i risultati — senza alcun intervento umano.

La coerenza è il secondo grande vantaggio. Poiché lo stesso modello di traduzione neurale elabora ogni stringa, la terminologia rimane uniforme in tutti i tipi di UDO. Non accadrà più che "Purchase Order" venga tradotto in un modo in una watchlist e in un altro nel titolo di una pagina composta.

C'è anche un vantaggio in termini di costi. L'OCI Language Service è un servizio pay-per-use con generose soglie gratuite. Per il volume relativamente ridotto di testo contenuto nelle stringhe UDO, il costo è trascurabile rispetto all'assunzione di traduttori umani o al pagamento di un sistema di gestione delle traduzioni separato.

Infine, questo modello è riutilizzabile. Una volta implementata l'autenticazione OCI e l'orchestrazione, è possibile estendere lo stesso framework ad altri servizi AI: document understanding per l'elaborazione delle fatture, AI generativa per gli approfondimenti sui widget o servizi di vision per il controllo qualità. Il livello di orchestrazione rimane lo stesso; cambiano solo l'endpoint API e il payload.

A cosa bisogna prestare attenzione?

La traduzione automatica non è perfetta, specialmente per la terminologia ERP specifica del settore. Un termine come "blanket order" o "lot disposition" potrebbe non essere tradotto accuratamente senza contesto. Considera di mantenere una lista di esclusione del glossarioUn elenco di parole o frasi che non devono essere tradotte dall'API, tipicamente termini specifici del dominio, nomi di prodotti o acronimi che devono rimanere nella loro lingua originale. — l'API di traduzione batch di OCI supporta un elenco di parole che non devono essere tradotte, l'ideale per mantenere intatti i termini specifici di JD Edwards.

Inoltre, pianifica una fase di revisione. Anche con una traduzione neurale di alta qualità, è una buona pratica far eseguire a un madrelingua una rapida revisione dell'output prima di pubblicare gli UDO in produzione. Puoi integrare questo passaggio nella tua gestione del ciclo di vita degli UDOIl processo di promozione degli UDO attraverso gli ambienti (sviluppo → test → produzione) utilizzando l'applicazione Object Management Workbench Web in JD Edwards. — traduci in un path code di sviluppo, revisiona e poi promuovi utilizzando il processo standard OMW Web.

Con la Release 26 di JD Edwards EnterpriseOne, Oracle ha introdotto ufficialmente questa funzionalità come parte dei nuovi percorsi di apprendimento per l'integrazione di OCI AI. Se la tua organizzazione utilizza un ambiente JD Edwards multilingue, l'automazione delle traduzioni UDO tramite OCI Language AI è uno dei risultati più rapidi che puoi ottenere: configurazione minima, payoff immediato e una solida base per un'ulteriore adozione dell'intelligenza artificiale.