Distribuire IBM Sterling Order Management su Azure

Database di Azure per PostgreSQL
File di Azure
Azure Red Hat OpenShift
Macchine virtuali di Azure
Rete virtuale di Azure

Questa architettura illustra un'implementazione di un ambiente Sterling Order Management Software (OMS) in Azure. Questo articolo non illustra in dettaglio come installare Sterling OMS. Per altre informazioni sul processo di installazione, vedere Installazione di Sterling Order Management Software.

I logo Red Hat sono marchi di Red Hat, Inc. Nessuna approvazione è implicita nell'uso di questi marchi. Apache® e Apache ActiveMQ sono marchi o marchi registrati di Apache Software Foundation negli Stati Uniti e/o in altri Paesi. L'uso di questi marchi non implica alcuna approvazione da parte di Apache Software Foundation.

Architettura

Diagramma dell'architettura che illustra i componenti e i servizi che supportano la distribuzione di un sistema di gestione degli ordini IBM Sterling OMS in Azure.

Scaricare un file di Visio di questa architettura.

È possibile implementare un carico di lavoro affinché sia accessibile internamente o esternamente. Usare la configurazione più adatta alle proprie esigenze.

Flusso di lavoro

L'architettura soddisfa i requisiti dell'infrastruttura nei modi seguenti:

  • Una piattaforma di hosting di contenitori viene utilizzata per distribuire carichi di lavoro ad alta disponibilità tra zone di disponibilità. Consigliamo Azure Red Hat OpenShift.
  • Un servizio di database completamente gestito funziona come database back-end per il sistema OMS. Sterling OMS supporta attualmente IBM Db2, Oracle Database e PostgreSQL. È consigliabile Database di Azure per PostgreSQL.
  • Una configurazione scalabile e a disponibilità elevata offre un ambiente per l'esecuzione di un broker di messaggi come IBM MQ conforme all'API Java Message Service (JMS). Il diagramma non include questa configurazione. A seconda dei requisiti, potrebbe trovarsi all'interno del cluster o all'esterno del cluster.
  • Gli endpoint privati isolano e aiutano a proteggere il traffico di rete a tutti i servizi connessi.
  • Le macchine virtuali (VM) di Azure aggiuntive e facoltative vengono usate per scopi di gestione e sviluppo.
  • Le condivisioni di File di Azure Premium e standard forniscono spazio di archiviazione per i file di log e altri dati di configurazione dell'applicazione.

Componenti

  • Azure Red Hat OpenShift offre cluster OpenShift completamente gestiti e a disponibilità elevata su richiesta. Questi cluster vengono monitorati e gestiti congiuntamente da Microsoft e Red Hat.

  • Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Rete virtuale per la comunicazione tra nodi, servizi di Azure e esigenze di connettività ibrida.

  • File di Azure offre condivisioni file completamente gestite nel cloud accessibili tramite i protocolli SMB e NFS. In questa soluzione, File di Azure ospita i dati con stato per i database e i sistemi che si trovano all'interno del cluster.

  • Azure Bastion è un servizio completamente gestito che fornisce accesso RDP e SSH alle macchine virtuali senza esposizione tramite indirizzi IP pubblici della macchina virtuale. Azure Bastion è facoltativo in questa soluzione. È possibile usare Azure Bastion e una subnet per fornire l'accesso con sicurezza avanzata a qualsiasi nodo di lavoro o macchine jump box opzionali.

  • Database di Azure per PostgreSQL è un servizio di database relazionale completamente gestito basato sul motore di database Postgres open source Database di Azure per PostgreSQL offre prestazioni prevedibili e scalabilità dinamica ed è appropriato per i carichi di lavoro critici per l'azienda. Offre un controllo granulare e flessibilità sulle funzioni di gestione del database e le impostazioni di configurazione.

  • Macchine virtuali di Azure offre una soluzione di infrastruttura come servizio (IaaS, Infrastructure as a Service). È possibile usare Macchine virtuali per distribuire risorse di elaborazione scalabili su richiesta. Questa soluzione usa macchine virtuali Linux in Azure per fornire un "jump box" per la gestione delle risorse e dei servizi basati su OMS.

Alternative

Se si ha connettività di rete nell'ambiente Azure, è possibile eseguire l'installazione da un computer esistente invece di utilizzare una VM Azure Linux..

I servizi seguenti in genere non sono necessari, ma sono alternative efficaci:

  • IBM Db2 in Azure è un'alternativa facoltativa a Database di Azure per PostgreSQL. Se si esegue IBM Db2 nelle macchine virtuali, acquisire familiarità con l'uso del software di clustering di Azure Load Balancer e Pacemaker per ottenere una disponibilità elevata per i server di database.
  • Azure NetApp Files supporta qualsiasi tipo di carico di lavoro con disponibilità elevata e prestazioni elevate. Azure NetApp Files è ideale per carichi di lavoro sensibili alle operazioni di I/O, ad esempio carichi di lavoro IBM Db2 eseguiti in macchine virtuali di Azure.
  • Oracle Database in Azure è un'alternativa facoltativa a Database di Azure per PostgreSQL.

Dettagli dello scenario

IBM Sterling OMS è un sistema di gestione degli ordini che offre una piattaforma completa di evasione degli ordini multicanale. Questo sistema include funzionalità come:

  • Visibilità e domanda di inventario in tempo reale.
  • Orchestrazione e flussi di lavoro di gestione ordini completamente configurabili.
  • Logistica inversa per i resi multicanale e lo stato dell'ordine di reso.

Una partnership tra Microsoft e il team IBM Sterling OMS garantisce che questa soluzione sia configurata per essere eseguita in modo ottimale in Azure. Questo articolo illustra una progettazione per l'esecuzione di Sterling OMS 10.0 e versioni successive su Azure per i clienti che dispongono del supporto di IBM e di un partner per l'installazione. Per risposte a domande specifiche sui prodotti, contatta il tuo team IBM.

Potenziali casi d'uso

Molti settori e settori usano soluzioni OMS, tra cui:

  • Vendita al dettaglio
  • E-commerce
  • Produzione

Per altri casi d'uso di OMS, vedere IBM Sterling Order Management.

Consigli

Questa guida supporta Sterling OMS 10.0 Q3 2022 e versioni successive. Queste versioni offrono le migliori opzioni di integrazione con Azure perché supportano PostgreSQL e la piattaforma contenitore Azure Red Hat OpenShift. Prima di creare una distribuzione personalizzata, usare la Guida introduttiva: Sterling Order Management in Azure per distribuire Sterling OMS. Quando si comprende quindi il funzionamento della distribuzione e della configurazione, è possibile determinare più rapidamente i requisiti di progettazione dell'implementazione.

Microsoft collabora a stretto contatto con IBM e altri partner per garantire che le linee guida, l'architettura e la guida all'avvio rapido offrono un'esperienza ottimale in Azure. Seguono le procedure consigliate descritte in Microsoft Azure Well-Architected Framework. Per assistenza oltre a questa documentazione, contattare il team dell'account IBM.

Prima di procedere con la distribuzione, è necessario rispondere alle domande seguenti sulla progettazione:

  • La distribuzione di Sterling OMS è una nuova distribuzione o si esegue la migrazione di una distribuzione esistente in Azure?
  • Quale piattaforma di database back-end prevedi di utilizzare? Quale grandezza di database sarà necessaria per i tuoi dati?
  • Quale tipo di broker di messaggi basato su JMS si prevede di usare?
  • Dove si prevede di distribuire il sistema di messaggistica:
    • Nello stesso cluster OpenShift?
    • Esterno al cluster su una piattaforma diversa o su macchine virtuali?
  • Si dispone di un registro contenitori esistente e si prevede di continuare a usarlo?
  • Qual è il numero e le dimensioni delle macchine virtuali necessarie per i nodi di lavoro?
  • Quali sono i requisiti di sicurezza correlati alla crittografia?
  • Quali sono i tuoi requisiti di accesso, e quali considerazioni sull'integrazione del provider di identità (IdP) hai?
  • Quali sono le esigenze di connettività? Quali regole del firewall sono necessarie per connettersi ai servizi interni ed esterni (in uscita)?
  • Qual è la tua strategia per l'alta disponibilità e il ripristino di emergenza?

Sterling OMS

Sterling OMS versione 10.0.2209.0 è stato testato in Azure. Ti consigliamo di utilizzare la versione più recente di Sterling OMS.

Prima di distribuire le risorse di Azure per supportare l'ambiente Sterling OMS, acquisire familiarità con i requisiti seguenti:

  • Per i requisiti di sistema di Sterling OMS, vedere Requisiti di sistema.
  • Sterling OMS ha una dipendenza da un sistema di database relazionale per la gestione dello stato e dei dati. È necessario anche un sistema di broker di messaggi abilitato per JMS per la comunicazione da servizio a servizio e i flussi di lavoro degli ordini. Sterling OMS supporta diverse opzioni di database e broker di messaggi che è possibile distribuire nell'ambiente. Per ulteriori informazioni, consultare le seguenti risorse:

Azure Red Hat OpenShift

Sterling OMS è stato testato con Azure Red Hat OpenShift versione 4.10.15. Prima di distribuire Azure Red Hat OpenShift:

  • Scegliere un dominio. Quando si distribuisce Azure Red Hat OpenShift, specificare un nome di dominio che viene aggiunto a tutti i servizi distribuiti nel cluster.
  • Determinare la visibilità dell'API e del traffico in ingresso. Decidere come si vuole che l'API del cluster OpenShift (per la gestione) e l'ingresso (per le applicazioni e i servizi distribuiti) siano con connessione Internet. Se si usa la connettività privata per nascondere l'API o l'ingresso, è possibile raggiungere questi endpoint solo da un computer in grado di raggiungere la rete in cui si distribuisce il servizio.
  • Calcola le dimensioni e i conteggi delle macchine virtuali di controllo e di lavoro. In Azure Red Hat OpenShift il conteggio dei controlli è un numero fisso, con una dimensione minima consigliata. I nodi di lavoro, che eseguono carichi di lavoro dell'applicazione come Sterling OMS, vengono dimensionati separatamente. quando si distribuisce l'istanza, considerare il numero necessario di nodi di lavoro nel cluster, oltre alle dimensioni appropriate di ogni nodo. Potrebbe essere necessario eseguire alcuni test e convalida per determinare i numeri e le dimensioni corretti. Questi valori dipendono dal numero di agenti nella distribuzione e dal numero di pod per ciascun tipo di agente che esegui. Dopo la distribuzione, è possibile modificare questi valori quando è necessario ridimensionare.

Per altre informazioni, vedere Prima di Iniziare per Azure Red Hat OpenShift.

Dimensionamento dell'ambiente

È consigliabile usare le macchine virtuali serie Ds più recenti come nodi di lavoro. Gli esempi sono le serie Dsv3, Dasv4, Dsv4, Dasv5 e Dsv5. Le versioni più recenti di queste macchine virtuali offrono prestazioni ottimali. Quando si distribuiscono più nodi, usare solo macchine virtuali con archiviazione Premium.

Specifiche del database

Poiché Sterling OMS dispone di varie opzioni di database back-end, è importante prima decidere la piattaforma in cui ospitare il database. È quindi possibile prendere decisioni sulle dimensioni della piattaforma. Tenere presenti le linee guida generali seguenti durante questo processo:

  • Database di Azure per PostgreSQL: a causa della natura delle opzioni di scalabilità e ridondanza, Database di Azure per PostgreSQL è il metodo preferito per l'hosting dei carichi di lavoro di Sterling OMS in Azure. Quando si implementa l'istanza:
    • Selezionare il livello di calcolo che corrisponde ai modelli di utilizzo. È consigliabile iniziare con un livello per utilizzo generico e selezionare un numero appropriato di core. La CPU, la memoria e gli I/O sono determinati dalla selezione delle dimensioni di calcolo.
    • Aggiungere una risorsa di archiviazione appropriata. Ricorda inoltre che un aumento dello spazio di archiviazione comporta un aumento dei costi e che non è possibile ridurre lo spazio di archiviazione che è stato provisioning. Di conseguenza, è importante conoscere le dimensioni iniziali dei dati e la crescita stimata.
    • Modificare i parametri del server, max_connections ad esempio che influiscono sulla capacità degli agenti di mantenere la connettività al database.
  • Db2 nelle macchine virtuali: quando si esegue Db2 in macchine virtuali di Azure, sono necessari diversi fattori complessi, ad esempio prestazioni e disponibilità. Per un articolo dettagliato su una distribuzione Db2 ad alte prestazioni in Azure, vedere Disponibilità elevata di IBM Db2 LUW in macchine virtuali di Azure in Red Hat Enterprise Linux Server. Questo articolo illustra le considerazioni sul ridimensionamento e sulle prestazioni. Illustra anche come distribuire un cluster Db2 a disponibilità elevata che usa Pacemaker.
  • Oracle: se si usa attualmente Oracle Database o se si prevede di eseguire la migrazione a Oracle, acquisire familiarità con le risorse seguenti per l'esecuzione di carichi di lavoro Oracle in Azure:

Specifiche della coda di messaggi

Sterling OMS richiede un broker di messaggi basato su JMS. Più comunemente viene usato IBM MQ. Il modo migliore per eseguire un'istanza IBM MQ a disponibilità elevata in Azure consiste nell'usare gli IBM MQ Helm Charts per le distribuzioni Kubernetes. È possibile distribuire questi grafici nel cluster Azure Red Hat OpenShift esistente in ruoli di lavoro separati per isolare i carichi di lavoro. È anche possibile distribuire e installare IBM MQ manualmente nelle macchine virtuali, se si preferisce.

Come parte della distribuzione standard, è possibile definire le code al momento della distribuzione, riducendo il tempo di configurazione necessario per eseguire le istanze. La distribuzione standard crea una sola istanza attiva e due passive del gestore code. Al termine della distribuzione, è possibile usare SSH per connettersi al pod leader corrente e definire il file di associazioni JMS. È quindi possibile usare tale file per creare la mappa di configurazione per la distribuzione di Sterling OMS.

IBM supporta anche altri sistemi di accodamento messaggi basati su JMS, ad esempio Apache ActiveMQ. Per altre informazioni, vedere Code di messaggi in Sterling Order Management Software. Le opzioni di distribuzione variano in base alla soluzione.

Considerazioni

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, ovvero un set di set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Microsoft Azure Well-Architected Framework.

Affidabilità

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni che l'utente ha preso con i clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Azure Red Hat OpenShift offre funzionalità predefinite per la riparazione automatica, la scalabilità e la resilienza per garantire il corretto funzionamento di Azure Red Hat OpenShift e Sterling OMS. Azure Red Hat OpenShift e Sterling OMS sono stati progettati per gestire guasti e il recupero. Un requisito fondamentale per l'auto-riparazione è la presenza di un numero sufficiente di nodi di lavoro. Per eseguire il ripristino da un errore di zona all'interno di un'area di Azure, i nodi di controllo e di lavoro devono essere bilanciati tra le zone di disponibilità.

Sterling OMS e Azure Red Hat OpenShift usano l'archiviazione del database per rendere persistente lo stato all'esterno del cluster Kubernetes. I log e altre risorse dell'applicazione vengono salvati in modo permanente in un account di archiviazione. Per garantire che le dipendenze di archiviazione continuino a funzionare durante un errore, utilizzare l'archiviazione ridondante a zona ogni volta possibile. Questo tipo di spazio di archiviazione rimane disponibile quando una zona ha esito negativo. La distribuzione del database deve prendere in considerazione anche le configurazioni a più zone.

Poiché l'errore umano è comune, è consigliabile distribuire Sterling OMS usando il maggior numero possibile di automazione. Per alcuni script di esempio per la configurazione dell'automazione completa end-to-end, vedere Guida introduttiva: Sterling Order Management in Azure su GitHub.

Sicurezza

La sicurezza offre garanzie contro attacchi intenzionali e l'abuso di dati e sistemi preziosi. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per Security.

Mantenere l'accesso e la visibilità sul ciclo di vita di manutenzione degli asset rappresenta una delle principali opportunità per la tua organizzazione di operare in modo efficiente e mantenere l'operatività. Per migliorare il comportamento di sicurezza dell'ambiente, è importante usare l'autenticazione sicura e mantenere aggiornate le soluzioni. Usare la crittografia per proteggere tutti i dati che si spostano all'interno e all'esterno dell'architettura.

Azure offre Sterling OMS usando i modelli di IaaS e piattaforma distribuita come servizio (PaaS). Microsoft crea protezioni di sicurezza nel servizio ai livelli seguenti:

  • Centro dati fisico
  • Rete fisica
  • Host fisico
  • Hypervisor

Valutare attentamente i servizi e le tecnologie selezionati per le aree sopra l'hypervisor, ad esempio la versione più recente con patch di Azure Red Hat OpenShift per una versione principale. Assicurarsi di fornire i controlli di sicurezza appropriati per l'architettura. L'utente è responsabile dell'applicazione di patch e della gestione della sicurezza dei sistemi IaaS. Microsoft assume tale ruolo per i servizi PaaS come Azure Red Hat OpenShift. Anche se è possibile avviare un aggiornamento per Azure Red Hat OpenShift, è completamente gestito da Microsoft e Red Hat. Per ulteriori informazioni sull'applicazione di patch e sull'aggiornamento di Azure Red Hat OpenShift, vedere Aggiornare un cluster Azure Red Hat OpenShift.

Usare i gruppi di sicurezza di rete per filtrare il traffico di rete da e verso le risorse nella propria rete virtuale. Con questi gruppi è possibile definire regole che concedono o negano l'accesso ai servizi Sterling OMS. Alcuni esempi:

  • Blocco dell'accesso a tutte le altre parti dell'infrastruttura distribuita, ad esempio porte e servizi specifici usati dal broker di messaggi o dal database back-end.
  • Controllare quali posizioni possono avere accesso a Sterling OMS e al cluster OpenShift.

I numeri di porta e gli intervalli che è necessario aprire dipendono da molti fattori. Ecco alcuni aspetti da considerare:

  • Porta 443, per la comunicazione da servizio a servizio.
  • Porte specifiche del database, ad esempio la porta 5432 per Database di Azure per PostgreSQL.
  • Porte della coda di messaggi, ad esempio la porta 1414 per IBM MQ.

Tenere presenti anche questi aspetti:

  • I nodi del cluster Azure Red Hat OpenShift devono avere accesso a Internet in uscita. Se non è possibile fornire questo accesso, questi nodi richiedono almeno l'accesso agli endpoint di registrazione dei servizi e di Azure Resource Manager.
  • IBM fornisce indicazioni per l'implementazione di più applicazioni Sterling OMS che condividono servizi comuni come un database back-end. Tali distribuzioni hanno anche considerazioni sul firewall all'interno dell'applicazione. Per altre informazioni, vedere Apertura delle porte del firewall per la comunicazione all'interno dell'app.

Se è necessario accedere agli altri nodi, non Azure Red Hat OpenShift, è possibile usare Facoltativamente Azure Bastion per accedere alle macchine virtuali. Per motivi di sicurezza, non è consigliabile esporre le macchine virtuali a una rete o a Internet senza configurare i gruppi di sicurezza di rete per controllare l'accesso.

La crittografia lato server (SSE) per l'archiviazione disco di Azure aiuta a proteggere i tuoi dati. SEE consente inoltre di soddisfare gli impegni di sicurezza e conformità dell'organizzazione. Con i dischi gestiti di Azure, SSE crittografa i dati inattivi quando vengono mantenuti nel cloud. Questo comportamento si applica per impostazione predefinita sia ai dischi del sistema operativo che ai dischi dati. OpenShift usa SSE per impostazione predefinita. Azure Red Hat OpenShift supporta anche chiavi di crittografia gestite dal cliente (CMEK) per i dischi del sistema operativo nel cluster.

Autenticazione

È consigliabile configurare OAuth per Azure Red Hat OpenShift. Per maggiori informazioni, consultare la sezione Panoramica dell'autenticazione e dell'autorizzazione nella documentazione di Azure Red Hat OpenShift.

Proteggere l'infrastruttura

Controllare l'accesso alle risorse di Azure da distribuire. Ogni sottoscrizione di Azure ha una relazione di fiducia con un tenant di Microsoft Entra. Usare il Controllo degli accessi in base al ruolo di Azure per concedere agli utenti interni dell'organizzazione le autorizzazioni corrette per le risorse di Azure. Concedere l'accesso assegnando ruoli di Azure a utenti o gruppi in un determinato ambito. L'ambito può essere un abbonamento, un gruppo di risorse o una risorsa. Assicurarsi di controllare tutte le modifiche apportate all'infrastruttura. Per maggiori informazioni sul controllo, consultare la sezione Log attività di Monitoraggio di Azure.

Ottimizzazione costi

L'ottimizzazione dei costi consiste nell'esaminare i modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Una distribuzione standard di SterlingOMS è costituita dai componenti seguenti: È possibile modificare molte di queste risorse basate su calcolo in base alle proprie esigenze. Ad esempio, è possibile aumentare le prestazioni dei nodi dell'agente IBM MQ per consentire una maggiore velocità effettiva.

Azure Red Hat OpenShift (per OMS)

  • Tre macchine virtuali di controllo (Standard_D8s_v5)
  • Tre macchine virtuali di lavoro (Standard_D8s_v5)

Risorse aggiuntive

  • Una rete virtuale (/16), con le subnet seguenti considerate:
    • Subnet del nodo di controllo Di Azure Red Hat OpenShift (/24)
    • Subnet del nodo di lavoro di Azure Red Hat OpenShift (/24)
    • Subnet dei dati, se necessario (/27)
    • Subnet vm aggiuntiva, se necessario (/27)
    • Subnet di gestione, se necessario (/30)
  • Un'istanza di Database di Azure per PostgreSQL
  • Un'istanza di Registro Azure Container
  • Due account di archiviazione di Azure.
  • Tre zone DNS
  • Due bilanciatori di carico
  • Una macchina virtuale jump box
  • Azure Bastion

Le singole distribuzioni possono differire, ad esempio, se si esegue Db2 in macchine virtuali di Azure o se si distribuisce IBM MQ nell'ambiente Azure Red Hat OpenShift. Per esaminare una stima di esempio, usare il calcolatore dei costi. Le configurazioni variano ed è necessario verificare la configurazione con il team di ridimensionamento IBM prima di finalizzare la distribuzione.

Distribuire lo scenario

Prima di iniziare, esaminare i requisiti per Sterling OMS in Requisiti di sistema. Assicurarsi anche di disporre delle risorse seguenti:

  • Accesso a una sottoscrizione di Azure con autorizzazione di Lettore
  • Registrazione dell'applicazione o nome dell'entità servizio con autorizzazioni Collaboratore e Amministratore Accesso Utenti per la sottoscrizione.
  • Dominio o sottodominio delegato a una zona DNS di Azure
  • Una chiave di diritti di accesso IBM Sterling OMS.
  • Dimensionamento del cluster IBM consigliato
  • Rete virtuale esistente o nuova rete virtuale, a seconda dei requisiti. Per un esempio di creazione di una nuova rete virtuale con due subnet vuote, vedere Esercitazione: Creare un cluster Azure Red Hat OpenShift 4.
  • Requisiti di disponibilità elevata e ripristino in caso di emergenza per la distribuzione specifica.
  • Un file di configurazione OMEnviroment, omenvironment.yaml, da usare quando si distribuisce Sterling OMS tramite openShift Operator Catalog.

Per una guida dettagliata per l'installazione di Azure Red Hat OpenShift e Sterling OMS in Azure, incluso come risolvere i prerequisiti, vedere Guida introduttiva: Gestione degli ordini Sterling in Azure.

Considerazioni sulla distribuzione

È consigliabile distribuire i carichi di lavoro usando l'infrastruttura come codice (IaC) anziché distribuire manualmente i carichi di lavoro, perché la distribuzione manuale può comportare errori di configurazione. I carichi di lavoro basati su contenitori possono essere sensibili alla configurazione errata, riducendo così la produttività.

Prima di creare l'ambiente, vedere Guida introduttiva: Gestione degli ordini in Sterling in Azure per comprendere i parametri di progettazione. La guida all'avvio rapido non è destinata a una distribuzione pronta per la produzione, ma è possibile usare le risorse della guida per arrivare a un meccanismo di distribuzione in produzione.

IBM offre servizi specializzati per facilitare l'installazione. Contattare il team IBM per assistenza.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi