Lo sviluppo custom in JD Edwards — BSFN, NER, APPL e automazione ERP — è il punto in cui la maggior parte delle implementazioni si gioca il proprio successo o il proprio debito tecnico per i dieci anni successivi. La piattaforma offre quattro strumenti principali per estendere il comportamento standard, e ogni scelta sbagliata su quale strumento usare per quale caso d'uso produce conseguenze che emergono solo quando è troppo tardi per cambiare strada economicamente: durante un upgrade, durante un retrofit, durante un Tools Release che modifica il comportamento sottostante in modi non documentati.

Questo articolo mette in fila i quattro strumenti — Business Function in C, Named Event Rules, applicazioni FDA e Orchestrator — descrive per cosa ciascuno è realmente adatto, e racconta i pattern di scelta che funzionano in produzione sui clienti reali. Nessuno dei quattro strumenti è universalmente migliore degli altri; ciascuno copre uno spazio di problemi specifico e la disciplina sta nel riconoscere quale spazio sta davanti agli occhi prima di scrivere la prima riga di codice.

Creare un'applicazione per JD Edwards (JDE) richiede una conoscenza approfondita di questo sistema ERP (Enterprise Resource Planning) e delle sue funzionalità. JDE è noto per essere altamente personalizzabile e estendibile attraverso il linguaggio di programmazione JDE, noto come JDE C BSFN (Business Function) o attraverso l'uso di strumenti come Orchestrator. Di seguito, ti fornisco un esempio di come potresti iniziare a scrivere un'applicazione personalizzata in JD Edwards utilizzando JDE C BSFN:

Considerare la nomenclatura delle business functionUnità di logica di programmazione riutilizzabili all'interno di JD Edwards per eseguire compiti specifici. come una mera scelta estetica introduce un sovraccarico operativo diretto che, nella nostra esperienza, gonfia i tempi di retrofittingL'attività di riadattamento del codice personalizzato quando si aggiorna il sistema a una nuova versione. degli upgrade di un terzo o più. Quando gli sviluppatori nominano arbitrariamente le C BSFN o le NERNamed Event Rules, un linguaggio di programmazione visuale proprietario di JD Edwards. custom, creano un debito tecnico che dilata silenziosamente la tipica fase di sviluppo di un upgrade di 6-9 settimane. L'implementazione di rigorose convenzioni di nomenclatura JDE BSFN per oggetti custom manutenibili garantisce che gli oggetti B55, B56 e B57 segnalino istantaneamente il loro sistema padre, l'area funzionale e la posizione di esecuzione (client rispetto al server) all'interno dell'Object Management Workbench (OMW)Lo strumento centrale di JD Edwards per la gestione del ciclo di vita e del trasferimento degli oggetti..

Un singolo jdeAllocAPI di JD Edwards utilizzata per riservare dinamicamente una porzione di memoria RAM durante l'esecuzione di un programma. gestito male o un handle di cache non rilasciato all'interno di una BSFNBusiness Function: un modulo di codice C o Java che esegue logica di business all'interno di JD Edwards. custom chiamata in un UBEUniversal Batch Engine: un processo che esegue report o elaborazioni massive di dati in background. ad alto volume come R42565 può mandare in crash un kernel CallObjectProcesso del server EnterpriseOne responsabile dell'esecuzione delle Business Function richieste dagli utenti. in pochi minuti, terminando istantaneamente decine di sessioni utente attive su quel JVMJava Virtual Machine: l'ambiente software che esegue le applicazioni Java e gestisce le risorse di sistema. specifico. Durante il troubleshooting di ambienti EnterpriseOne 9.2 instabili, spesso tracciamo processi zombie persistenti e leak di memoriaCondizione in cui un programma occupa RAM senza rilasciarla, esaurendo progressivamente le risorse del server. riconducibili a errori comuni di gestione della memoria JDE BSFN nel codice custom, piuttosto che a problemi sottostanti del database o del middleware OCIOracle Cloud Infrastructure: la piattaforma di servizi cloud fornita da Oracle per ospitare applicazioni e database..

Nelle nostre revisioni del codice in decine di ambienti JDE 9.2, riscontriamo regolarmente che una parte significativa delle business function C personalizzate (BSFN)BSFN: moduli di codice scritti in C o Event Rules che eseguono logica di business specifica all'interno di JD Edwards. — spesso da un terzo alla metà — duplica inutilmente la logica Oracle standard. Gli sviluppatori spesso clonano interi moduli come B4200310 o B1200010 solo per eseguire una singola validazione, invece di implementare un pulito esempio di chiamata JDE BSFN jdeCallObjectAPI fondamentale di JD Edwards utilizzata per invocare una business function da un programma C o da un'altra funzione. per eseguire una business function riutilizzabile. Questo codice ridondante si rompe durante gli aggiornamenti perché bypassa gli aggiornamenti di continuous deliveryModello di rilascio software che prevede il rilascio frequente e automatizzato di piccoli aggiornamenti e correzioni. di Oracle. L'approccio più corretto è chiamare la business function standard dinamicamente dal proprio codice C personalizzato.

Vedo ancora sviluppatori senior commettere l'errore di affidarsi esclusivamente ai valori di ritorno ER_ERROR o ER_SUCCESS nelle business function C. In un'integrazione di ordini di vendita ad alto volume che gira tramite AISApplication Interface Services, un server che permette l'integrazione tra JD Edwards e applicazioni esterne tramite servizi web REST., restituire un semplice codice di fallimento senza gestire correttamente lo stack degli errori DDData Dictionary, il repository centrale in JD Edwards che definisce le proprietà e le validazioni di tutti i campi dati. interno del motore JDEJD Edwards EnterpriseOne, un sistema ERP (Enterprise Resource Planning) di Oracle per la gestione dei processi aziendali. porta a fallimenti silenziosi o kernel bloccati. L'implementazione di un pattern pulito di gestione degli errori BSFNBusiness Function, un'unità di codice logico (in C o NER) che esegue operazioni specifiche all'interno del sistema JDE. per restituire warning ed errori bloccanti (hard errors) garantisce che il codice comunichi esplicitamente gli stati di esecuzione al runtime.