ITMI20130390U1 - Metodi e apparato per generatori di endpoint dinamici, individuazione e mediazione (brokerage) di oggetti remoti dinamici - Google Patents

Metodi e apparato per generatori di endpoint dinamici, individuazione e mediazione (brokerage) di oggetti remoti dinamici Download PDF

Info

Publication number
ITMI20130390U1
ITMI20130390U1 IT000390U ITMI20130390U ITMI20130390U1 IT MI20130390 U1 ITMI20130390 U1 IT MI20130390U1 IT 000390 U IT000390 U IT 000390U IT MI20130390 U ITMI20130390 U IT MI20130390U IT MI20130390 U1 ITMI20130390 U1 IT MI20130390U1
Authority
IT
Italy
Prior art keywords
endpoint
business object
configuration
endpoints
server
Prior art date
Application number
IT000390U
Other languages
English (en)
Inventor
Richard Grimes Cowan
Preez Jacobus Du
Anthony Thomas Petro
Original Assignee
Sourcecode Technology Holdings Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sourcecode Technology Holdings Inc filed Critical Sourcecode Technology Holdings Inc
Publication of ITMI20130390U1 publication Critical patent/ITMI20130390U1/it

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4418—Suspend and resume; Hibernate and awake
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Transfer Between Computers (AREA)
  • Selective Calling Equipment (AREA)
  • Arrangements For Transmission Of Measured Signals (AREA)
  • Stored Programmes (AREA)

Description

“METODI E APPARATO PER GENERATORI DI ENDPOINT DINAMICI, INDIVIDUAZIONE E MEDIAZIONE (BROKERAGE) DI OGGETTI REMOTI DINAMICI”
CAMPO TECNICO DELL’INVENZIONE
La presente domanda riguarda in generale generatori di endpoint dinamici e più specificamente metodi e un apparato per generatori di endpoint dinamici che pubblicano automaticamente un endpoint per oggetti aziendali in modo da permettere a dispositivi client remoti di individuare e accedere con facilità agli oggetti aziendali.
PREMESSA ALL’INVENZIONE
Dato il numero crescente di sorgenti di informazioni nelle organizzazioni, diventa sempre più difficile per i consumatori delle informazioni potervi accedere in un modo logico e strutturato che sia correlabile ai tradizionali oggetti aziendali con cui essi hanno familiarità all’interno delle proprie organizzazioni (per es. clienti, cespiti, fornitori, personale ecc.). I dati che provengono dai sistemi esistenti vengono tipicamente resi disponibili in un modo tecnicamente complesso e che richiede significative competenze tecniche e di sviluppo per renderli utilizzabili dagli utenti non tecnici dell’organizzazione. Gli utenti non tecnici devono poter essere in grado di aggiungere informazioni nell’ambito della definizione di un oggetto aziendale logico senza coinvolgere competenze tecniche o di sviluppo. Gli utenti tecnici o non tecnici dei dati devono poter essere in grado di accedere alle proprie informazioni da molteplici sorgenti di informazioni/dati in un modo strutturato che sia correlabile agli oggetti aziendali, mantenendo la flessibilità per aggiungere definizioni di informazioni aggiuntive agli oggetti aziendali esistenti o per creare nuovi oggetti aziendali da sorgenti dati nuove o esistenti senza necessità di sviluppo di soluzioni complesse.
I sistemi d’integrazione di applicazioni aziendali esistenti (EAI, Enterprise Application Integration) possono essere utilizzati, in combinazione con strumenti di sviluppo, per sviluppare soluzioni personalizzate per rendere più accessibili informazioni e dati; tuttavia, tali soluzioni sono tipicamente codificate in forma rigida e richiedono significative competenze tecniche e di sviluppo per essere mantenute e modificate nel tempo. Inoltre, gli operatori informatici sono limitati dalle informazioni e dai moduli aziendali statici che vengono loro presentati dalle applicazioni per soluzioni aziendali o dalle applicazioni personalizzate che essi utilizzano su base quotidiana. In aggiunta, gli strumenti di automazione dei processi esistenti non forniscono il livello necessario dei concetti e strumenti di modellazione in grado di permettere a utenti tecnici o non tecnici di creare come autori una soluzione per processi aziendali completa in un singolo ambiente di modellazione/automazione.
Questi problemi possono essere risolti utilizzando sorgenti d’integrazione di applicazioni aziendali (EAI) (per es. software EAI, Servizi Web, API applicativi) per fornire un framework di livello superiore (per es. servizi di adattatore e runtime broker) con relativi componenti di soluzioni (per es. strumenti e interfacce utente) che permettano a utenti tecnici e non tecnici di creare come autori oggetti aziendali logici, incluse definizioni dei dati (per es. nome, cognome del cliente ecc.) e azioni o metodi (per es. salva, carica, cancella) da molteplici sorgenti di dati nuove o esistenti. Gli utenti possono combinare dati provenienti da molteplici sorgenti in una singola definizione dell’oggetto aziendale, incluse definizioni dei dati e metodi/azioni. L’oggetto aziendale logico è un oggetto avanzato (smart object) che espone una singola struttura di dati logici e vista dell’oggetto aziendale, nonché un singolo insieme di metodi logici che sono associati all’oggetto aziendale. L’oggetto aziendale è dinamico, e la sua definizione può essere modificata sia aggiungendo sia rimuovendo dati o azioni senza necessità di coinvolgere risorse tecniche o di sviluppo per riconfigurare o ricompilare gli oggetti aziendali reali.
Tuttavia, una volta che un oggetto aziendale è stato creato, non è facile per i dispositivi client remoti accedervi e consumarlo. Le attuali tecnologie richiedono che sia definito un endpoint prima di poter consumare l’oggetto aziendale attraverso le tecnologie dei servizi web esistenti. Un endpoint è utilizzato per specificare i requisiti d’interazione tra il dispositivo client e l’oggetto aziendale. Per esempio, il dispositivo client invia un messaggio all’endpoint dell’oggetto aziendale quando desidera utilizzare l’oggetto aziendale, e il messaggio viene formattato in base alle informazioni specificate dall’endpoint. Un oggetto aziendale può avere molteplici endpoint che consentono ai clienti di consumare tale oggetto aziendale in diversi modi.
Tipicamente, un endpoint è definito da un indirizzo, un legame (binding) e un contratto. Un indirizzo è la locazione in cui risiede l’endpoint.
Un binding specifica in che modo un oggetto aziendale può essere consumato, per esempio informazioni di codifica o protocollo. Un contratto per ogni oggetto elenca le operazioni esposte dall’oggetto aziendale. Tutte queste informazioni devono essere specificate prima che un oggetto aziendale possa essere utilizzato da un dispositivo client remoto.
Questo approccio presenta diversi problemi. Il contratto deve essere generato manualmente per ogni oggetto. Poiché l’endpoint comprende il contratto, anche l’endpoint è generato manualmente per ogni oggetto. La generazione manuale di un contratto (e quindi dell’endpoint) può essere dispendiosa in termini di costi e di tempo ed è suscettibile di errore da parte dell’utente. Inoltre, l’endpoint può divenire obsoleto se non viene aggiornato non appena si aggiorna l’oggetto aziendale e può succedere che l’utente faccia affidamento su informazioni dell’endpoint che non rappresentano in maniera accurata l’oggetto aziendale.
Pertanto, esiste la necessità nell’arte di un modo più efficiente, redditizio e accurato per permettere a dispositivi client di accedere e consumare oggetti aziendali remoti.
RIASSUNTO
Il metodo e apparato qui descritti permettono a utenti tecnici e non tecnici di far sì che dispositivi client possano individuare, accedere e consumare oggetti senza necessità di generare manualmente un endpoint per ogni oggetto. Un endpoint può essere qualsiasi informazione di cui un dispositivo client necessita prima che il dispositivo client possa comunicare con un oggetto aziendale. Il client può richiedere di consumare o utilizzare un oggetto aziendale, e le informazioni dell’endpoint, per esempio il contratto, vengono costruite e pubblicate automaticamente. Per il client è come se esistesse già un endpoint, anche se questo è stato generato nel momento in cui il client ha richiesto l’oggetto aziendale. Oppure, l’endpoint viene costruito e pubblicato automaticamente nel momento in cui viene creato l’oggetto aziendale.
Questo intero processo avviene senza la reale immissione di informazioni di indirizzo, binding o contratto che siano rappresentative dell’oggetto remoto. Le informazioni dell’endpoint sono dinamiche e rappresentano in maniera accurata le informazioni più aggiornate dell’oggetto aziendale. In questo modo, un dispositivo client può facilmente individuare e richiedere un endpoint per un oggetto aziendale.
Ulteriori caratteristiche e vantaggi sono qui descritti e appariranno evidenti dalla Descrizione Dettagliata e dalle figure che seguono.
BREVE DESCRIZIONE DELLE FIGURE
La Fig. 1 è uno schema a blocchi di livello alto di un sistema di comunicazione di esempio.
La Fig. 2 è uno schema a blocchi più dettagliato che mostra un esempio di un dispositivo di elaborazione.
La Fig. 3 è uno schema a blocchi che mostra connessioni di esempio tra una pluralità di sorgenti dati e un modulo elettronico tramite un mediatore (broker) di oggetti.
La fig. 4 è uno schema a blocchi che mostra connessioni di esempio tra sorgenti dati e oggetti aziendali.
La fig. 5 è una vista più dettagliata di una pagina ordini clienti di esempio e delle connessioni associate a un oggetto aziendale clienti e a un oggetto aziendale ordini.
La fig. 6 è un diagramma di flusso di un processo broker di oggetti di esempio.
La fig. 7 è un diagramma di flusso di un processo modulo di esempio. La fig. 8 è una schermata di uno strumento di progettazione di flussi di lavoro (workflow) di esempio che permette a un utente di definire una mappa di risorse.
La fig. 9 è una schermata di uno strumento di progettazione di workflow di esempio che permette a un utente di definire una mappa di processi.
La fig. 10 è una mappa di processi di esempio con una regione localizzata della mappa di processi evidenziata.
La fig. 11 è una schermata di una striscia (strip) di attività di esempio. La fig. 12 è una schermata di una guida (wizard) di configurazione di esempio in uno stato di rotazione parziale.
La fig. 13 è una schermata del wizard di configurazione di esempio in uno stato di rotazione completa.
La fig. 14 è una schermata del wizard di configurazione di esempio con una finestra a comparsa.
La fig. 15 è un diagramma di flusso di un processo wizard di configurazione di esempio.
La fig. 16 è uno schema che mostra un esempio di un sistema che implementa un generatore di endpoint dinamici per permettere a un’applicazione di consumare oggetti aziendali.
La fig. 17 è un diagramma di flusso che illustra un processo di esempio per generare, implementare e pubblicare un oggetto aziendale, generando automaticamente un endpoint dinamico per l’oggetto aziendale, e permettendo a un dispositivo client di consumare l’oggetto aziendale utilizzando l’endpoint dinamico.
La fig. 18 è una schermata di uno strumento di progettazione di esempio che permette a un utente di creare un oggetto aziendale vuoto.
La fig. 19 è una schermata di un oggetto aziendale Prodotti di esempio. La fig. 20 è una schermata di esempio di proprietà di un oggetto aziendale.
La fig. 21 è una schermata di esempio d’implementazione di un oggetto aziendale.
La fig. 22 è una schermata di esempio di pubblicazione di un oggetto aziendale su un server.
La fig. 23 è un diagramma di flusso che illustra un esempio di configurazione di endpoint per un oggetto aziendale.
La fig. 24 è una schermata di esempio di un servizio che permette ai client di utilizzare i metodi associati a un oggetto aziendale.
La fig. 25 è una schermata di esempio di endpoint WCF e REST.
La fig. 26 è una schermata di esempio di codice che può essere utilizzato per testare se un servizio funziona.
La fig. 27 è una schermata di esempio di un endpoint WCF in WSDL. La fig. 28 è una schermata di esempio di creazione di una nuova applicazione per dispositivo client.
La fig. 29 è una schermata di esempio di aggiunta di un riferimento al servizio.
La fig. 30 è una schermata di esempio di un client che comunica con un oggetto aziendale con l’utilizzo di un endpoint dinamico.
La fig. 31 è una schermata di esempio di metadati dell’oggetto aziendale forniti a un dispositivo client.
La fig. 32 è una schermata di esempio di dati e metodi dell’oggetto aziendale forniti a un dispositivo client.
La fig. 33 è una schermata di esempio di un dispositivo client senza alcun record di oggetti.
La fig. 34 è una schermata di esempio di un record di un oggetto aziendale creato utilizzando un endpoint dinamico.
La fig. 35 è una schermata di esempio di molteplici record di un oggetto aziendale creati utilizzando un endpoint dinamico.
La fig. 36 è una schermata di esempio di accesso a un metodo per un oggetto che utilizza un endpoint REST.
La fig. 37 è una schermata di esempio di accesso a un altro metodo per un oggetto che utilizza un endpoint REST.
La fig. 38 è una schermata di esempio di accesso a un metodo per un oggetto che utilizza un endpoint REST in XML.
La fig. 39 è una schermata di esempio di accesso a un metodo per un oggetto che utilizza un endpoint REST in un feed Atom.
DESCRIZIONE DETTAGLIATA
Il presente sistema è più facilmente realizzabile in un sistema di comunicazione di rete. Uno schema a blocchi di livello alto di un sistema di comunicazione di rete di esempio 100 è illustrato in Fig. 1. Il sistema illustrato 100 comprende uno o più dispositivi client 102, uno o più router 106 e una pluralità di diverse sorgenti dati 108 comprendenti server per database 110 e/o database 112. I dati trasferiti ai/dai dispositivi client 102 dalle/alle sorgenti dati 108 sono gestiti da uno o più server per broker di oggetti 114. Ognuno di questi dispositivi può comunicare con gli altri tramite una connessione a uno o più canali di comunicazione 116 come Internet e/o altra rete di dati, compresa, a titolo non limitativo, qualsiasi rete geografica o rete locale idonea. Si apprezzerà che qualsiasi dispositivo tra quelli qui descritti può essere connesso a un altro direttamente anziché attraverso una rete.
Le sorgenti dati 108 memorizzano una pluralità di file, programmi e/o pagine web in uno o più database 112 per l’uso da parte dei dispositivi client 102. Per esempio, una sorgente dati può memorizzare informazioni di clienti. Le sorgenti dati 108 possono essere connesse direttamente a un server per database 110 e/o tramite una o più connessioni di rete.
Una singola sorgente dati 108 e/o un singolo server per broker di oggetti 114 può interagire con un ampio numero di altri dispositivi. Analogamente, ogni sorgente dati 108 e/o un server per broker di oggetti 114 è tipicamente un elaboratore di fascia alta con un’elevata capacità di memorizzazione, uno o più microprocessori veloci e una o più connessioni di rete ad alta velocità. Al contrario, rispetto a un tipico server, ogni dispositivo client 102 tipicamente comprende una minore capacità di memorizzazione, un singolo microprocessore e una singola connessione di rete.
Uno schema a blocchi più dettagliato dei sistemi elettrici di un dispositivo di elaborazione (per es., un dispositivo client portatile 102, un dispositivo client PC 102, un router 106, un server per database 110 e/o un server per broker di oggetti 114) è illustrato in Fig. 2. Sebbene i sistemi elettrici di tali dispositivi di elaborazione possano essere simili, le differenze strutturali tra questi dispositivi sono ben note. Per esempio, un tipico dispositivo client portatile 102 è piccolo e leggero rispetto a un tipico server per database 110.
Il dispositivo di elaborazione di esempio 102, 106, 110, 114 comprende un’unità principale 202 che preferibilmente comprende uno o più processori 204 elettricamente accoppiati da un bus di indirizzi/dati 206 a uno o più dispositivi di memoria 208, altra circuiteria di elaboratore 210 e uno o più circuiti di interfaccia 212. Il processore 204 può essere qualsiasi processore idoneo, come un microprocessore della famiglia di microprocessori INTEL PENTIUM®. La memoria 208 preferibilmente comprende memoria volatile e non volatile. Preferibilmente, la memoria 208 memorizza un programma software che interagisce con gli altri dispositivi del sistema 100 come descritto nel seguito. Questo programma può essere eseguito dal processore 204 in qualsiasi maniera idonea. La memoria 208 può anche memorizzare dati digitali indicativi di documenti, file, programmi, pagine web ecc. recuperati da un altro dispositivo di elaborazione e/o caricati tramite un dispositivo di input 214.
Il circuito di interfaccia 212 può essere implementato utilizzando qualsiasi standard di interfaccia idoneo, come un’interfaccia Ethernet e/o un’interfaccia bus seriale universale (USB, Universal Serial Bus). Uno o più dispositivi di input 214 possono essere connessi al circuito di interfaccia 212 per l’immissione di dati e comandi nell’unità principale 202. Per esempio, il dispositivo di input 214 può essere una tastiera, mouse, touchscreen, track pad, track ball, isopoint e/o sistema di riconoscimento vocale.
Anche uno o più display, stampanti, altoparlanti e/o altri dispositivi di output 216 possono essere connessi all’unità principale 202 tramite il circuito di interfaccia 212. Il display 216 può essere un tubo a raggi catodici (CRT), display a cristalli liquidi (LCD) o qualsiasi altro tipo di display. Il display 216 genera visualizzazioni di dati generati durante il funzionamento del dispositivo di elaborazione 102, 106, 110, 114. Per esempio, il display 216 può essere utilizzato per visualizzare pagine web ricevute dal server per broker di oggetti 114, inclusi dati provenienti da molteplici sorgenti dati 108. Le visualizzazioni possono comprendere prompt per input umano, statistiche di runtime, valori calcolati, dati ecc.
Anche uno o più dispositivi di memorizzazione 218 possono essere connessi all’unità principale 202 tramite il circuito di interfaccia 212. Per esempio, un’unità disco rigido, un’unità CD, un’unità DVD e/o altri dispositivi di memorizzazione possono essere connessi all’unità principale 202. I dispositivi di memorizzazione 218 possono memorizzare qualsiasi tipo di dati idonei.
Il dispositivo di elaborazione 102, 104 può anche scambiare dati con altri dispositivi di rete 220 tramite una connessione alla rete 116. La connessione di rete può essere qualsiasi tipo di connessione di rete, come una connessione Ethernet, linea digitale di abbonato (DSL, Digital Subscriber Line), linea telefonica, cavo coassiale ecc. Agli utenti del sistema 100 può essere richiesto di registrarsi presso uno o più dei dispositivi di elaborazione 102, 106, 110, 114. In tal caso, ogni utente può scegliere un identificativo di utente (per es. indirizzo e-mail) e una password che possono essere richiesti per l’attivazione dei servizi. L’identificativo di utente e la password possono essere trasmessi attraverso la rete 116 utilizzando una criptazione integrata nel browser web dell’utente. In alternativa, l’identificativo di utente e/o la password possono essere assegnati dal dispositivo di elaborazione 102, 106, 110, 114.
In una forma realizzativa, un utente presso un dispositivo client 102 visualizza e/o modifica dati provenienti da una pluralità di diverse sorgenti dati 108 tramite un modulo elettronico interattivo. Uno schema a blocchi di esempio che mostra le connessioni tra una pluralità di sorgenti dati 108 e un modulo elettronico 302 tramite un processo broker di oggetti 304 è illustrato in Fig. 3. Generalmente, il processo broker di oggetti 304 (descritto in dettaglio nel seguito con riferimento alla Fig. 6) compila i dati in una varietà di formati nativi diversi provenienti dalle diverse sorgenti dati 108 (per es., diversi sistemi di database legacy) in oggetti aziendali standardizzati 306, 308 (per es., in un formato dichiarativo come il linguaggio di marcatura estensibile (XML, Extensible Markup Language)). Un utente può quindi visualizzare i dati utilizzando uno o più moduli elettronici 302, 310, 312. Inoltre, l’utente può manipolare i dati e/o aggiungere dati tramite i moduli elettronici 302, 310, 312. In tal caso, il processo broker di oggetti 304 accetta i dati tramite gli oggetti aziendali 306, 308 e rimemorizza i dati nelle sorgenti dati 108 nel formato nativo corretto.
In questo esempio, le sorgenti dati 108 comprendono una sorgente dati di pianificazione delle risorse aziendali (ERP) 314, una sorgente dati di gestione delle relazioni con i clienti (CRM, Customer Relationship Management) 316, una sorgente dati personalizzata 318, una sorgente dati aggiuntiva 320 e una sorgente dati di funzioni 322. Inoltre, nel sistema sono compresi un servizio ruoli 323 e una memoria dati di oggetti 325. Tipicamente, una sorgente dati ERP 314 memorizza dati relativi a crediti, debiti, voci d’inventario, ecc. Tipicamente, una sorgente dati CRM 316 memorizza dati relativi a potenziali clienti, offerte, ordini, ecc. Una sorgente dati personalizzata 318 è una sorgente dati 108 che non è considerata come un prodotto commerciale standard. Per esempio, un’azienda può avere una sorgente dati personalizzata che memorizza informazioni di produzione in tempo reale. Alcune sorgenti dati 108 possono utilizzare un server intermediario per la comunicazione. Per esempio, la sorgente dati ERP 314 utilizza un server BizTalk 324.
La sorgente dati aggiuntiva 320 memorizza dati associati a campi modulo aggiunti dall’utente che non sono supportati da una delle altre sorgenti dati 108. Per esempio, un’azienda può lanciare un programma di carte acquisto per clienti abituali e avere necessità di memorizzare un numero di carta per ogni partecipante. Pertanto, un utente può aggiungere un campo numerico di acquirente abituale a un modulo esistente contenente dati legacy. Poiché le sorgenti dati esistenti 108 in questo esempio non comprendono un campo numerico di acquirente abituale, il campo numerico di acquirente abituale e i dati associati sono memorizzati dalla sorgente dati aggiuntiva 320.
Per manipolare i dati in una particolare sorgente dati 108, il processo broker di oggetti 304 preferibilmente richiama metodi integrati nella sorgente dati associata 108. Per esempio, ogni sorgente dati 108 tipicamente comprende metodi per memorizzare/recuperare dati sulla/dalla sorgente dati 108 (per es. la sorgente dati CRM può supportare un metodo “LoadContact” come descritto in dettaglio nel seguito). Inoltre, il sistema 300 permette a un utente di creare come autore le proprie funzioni. Per esempio, un utente può avere necessità di applicare uno sconto a particolari clienti. Tuttavia, le sorgenti dati esistenti 108 possono non comprendere un metodo per calcolare lo sconto. Pertanto, l’utente può creare come autore una funzione “CalcDiscount” come descritto nel seguito. Le funzioni definite dall’utente possono utilizzare dati provenienti da più di una sorgente dati 108. Le definizioni per queste funzioni definite dall’utente vengono quindi memorizzate nella sorgente dati di funzioni 322.
Le funzioni definite dall’utente possono essere create utilizzando uno strumento d’interfaccia grafica utente. Per esempio, i parametri per una funzione definita dall’utente possono essere definiti selezionando una rappresentazione grafica del parametro associato a un oggetto aziendale. Preferibilmente, le funzioni definite dall’utente sono memorizzate come frammenti di codice (snippet). Gli snippet comprendono una porzione di struttura che definisce la funzione e una porzione d’interfaccia utente che fornisce all’utente un modo per testare la funzione. Per esempio, la porzione di struttura può essere memorizzata come XML e la porzione d’interfaccia utente può essere memorizzata come HTML nello stesso file.
Alcune funzioni definite dall’utente possono essere eseguite dai dispositivi client 102 riducendo così la comunicazione con il server 110, 114. Altre funzioni definite dall’utente possono richiedere di essere eseguite sul lato server. Preferibilmente, si determina se una particolare funzione deve essere eseguita sul lato client o sul lato server, e un indicatore di quanto determinato viene memorizzato con lo snippet della funzione. Per esempio, le funzioni definite dall’utente che sono costruite da particolari primitivi predefiniti (per es. aggiungi, moltiplica, esegui loop, meno di, ecc.) possono essere determinate come eseguibili dal dispositivo client 200, mentre altre funzioni definite dall’utente che comprendono consultazioni di database (per es. statement SQL) possono essere determinate come eseguibili da un server 110, 114.
Dal punto di vista di un utente, i dati provenienti dalle sorgenti dati 108 (nonché i dati calcolati da dati delle sorgenti dati 108, per es. uno sconto) sono visualizzati utilizzando uno o più moduli elettronici 302, 310, 312. Inoltre, l’utente può manipolare i dati e/o aggiungere dati tramite i moduli elettronici 302, 310, 312. I moduli 302, 310, 312 possono essere combinati in pagine 302 e un modulo può utilizzare dati provenienti da più di una sorgente dati 108. Per esempio, la pagina ordini clienti 302 combina il modulo contatto clienti 310 e il modulo elenco ordini 312 (come descritto in dettaglio nel seguito con riferimento alla Fig. 5). Inoltre, porzioni di moduli e/o interi moduli che fanno parte di una pagina più ampia possono essere bloccati in modo che solo particolari utenti possano modificare quella porzione del modulo o della pagina.
Per facilitare i moduli 302, 310, 312 che combinano i dati provenienti da diverse sorgenti dati 108, il sistema 300 impiega un processo broker di oggetti 304 (descritto in dettaglio nel seguito con riferimento alla Fig. 6) e un processo modulo 326 (descritto in dettaglio nel seguito con riferimento alla Fig. 7). In una forma realizzativa, il processo broker di oggetti 304 è codice ASP eseguibile sul server per broker di oggetti 114 e il processo modulo 326 è JavaScript eseguibile su un dispositivo client 102. Il processo broker di oggetti 304 compila i dati in una varietà di formati nativi diversi dalle diverse sorgenti dati 108 in oggetti aziendali standardizzati 306, 308 (per es., file XML). Inoltre, il processo broker di oggetti 304 accetta i dati attraverso gli oggetti aziendali 306, 308 e rimemorizza i dati sulle sorgenti dati 108 nel formato nativo corretto.
Più specificamente, il processo broker di oggetti 304 utilizza una pluralità di servizi broker per comunicare con le sorgenti dati 108. Preferibilmente, si utilizza un singolo servizio broker per ogni sorgente dati 108. In questo esempio, il processo broker di oggetti 304 comprende un servizio broker ERP 328, un servizio broker CRM 330, un servizio broker personalizzato 332, un servizio broker aggiuntivo 334 e un servizio broker di funzioni 336. Ogni servizio broker 328, 330, 332, 334, 336 è progettato per comunicare con la sorgente dati associata 108 utilizzando i formati e i protocolli nativi della sorgente dati.
Ogni servizio broker 328, 330, 332, 334, 336 quindi espone automaticamente le proprietà e i metodi della sorgente dati associata 108 come proprietà e metodi standardizzati 338 per l’uso da parte degli oggetti aziendali 306, 308. Per esempio, il servizio broker ERP 328 comunica con la sorgente dati ERP 314 tramite il server BizTalk 324 ed espone le proprietà e i metodi della sorgente dati ERP 314 all’oggetto aziendale clienti 306 e all’oggetto aziendale ordini 308 come file XML. Se nuove proprietà e/o metodi si rendono disponibili da una sorgente dati 108, il servizio broker associato preferibilmente rileva queste nuove proprietà e/o metodi e automaticamente espone le nuove proprietà e/o metodi per l’uso da parte degli oggetti aziendali 306, 308. Gli oggetti aziendali 306, 308 possono comprendere alcune o tutte le proprietà e i metodi esposti 338. Ogni oggetto aziendale 306, 308 quindi espone le sue proprietà e i metodi compresi 340 nel processo modulo 326.
Il processo modulo 326 richiama i metodi degli oggetti aziendali 340 in risposta a eventi modulo e popola i moduli 302, 310, 312 con i dati provenienti dalle proprietà degli oggetti aziendali 340. Per esempio, un utente può premere un pulsante “Load” sulla pagina ordini clienti 302, facendo sì che il processo modulo 326 richiami uno o più metodi 340 esposti dagli oggetti aziendali 306, 308. Questo, a sua volta, fa sì che il processo broker di oggetti 304 recuperi i dati appropriati da una o più sorgenti dati 108. I dati vengono quindi restituiti come proprietà degli oggetti aziendali 306, 308 e il processo modulo 326 utilizza i dati per popolare i moduli 310, 312.
Inoltre, il processo modulo 326 può memorizzare valori nelle proprietà degli oggetti aziendali 340 e richiamare metodi per rimemorizzare i dati nuovi/modificati nella sorgente dati appropriata 108 tramite il processo broker di oggetti 304. Per esempio, un modulo può accettare un nuovo valore per l’indirizzo di un cliente e chiamare un metodo UpdateContact per memorizzare il nuovo indirizzo nella sorgente dati appropriata 108.
Uno schema a blocchi più dettagliato che mostra queste connessioni tra le sorgenti dati di esempio 108 e gli oggetti aziendali di esempio 306, 308 è illustrato in Fig. 4. In questo esempio, l’oggetto aziendale clienti 306 è connesso alla sorgente dati ERP 314 e alla sorgente dati CRM 316. L’oggetto aziendale ordini 308 è connesso alla sorgente dati ERP 314, alla sorgente dati aggiuntiva 320 e alla sorgente dati di funzioni 322. Tali connessioni logiche possono essere definite in qualsiasi maniera idonea. Per esempio, può essere utilizzata un’interfaccia grafica utente per permettere a un utente di tracciare linee di connessione tra rappresentazioni grafiche delle sorgenti dati 108 e rappresentazioni grafiche degli oggetti aziendali 306, 308.
Tali connessioni logiche vengono mantenute dal processo broker di oggetti 304. Per esempio, i dati per popolare il modulo contatto clienti 310 e il modulo elenco ordini 312 sono portati nell’oggetto aziendale clienti 306 e nell’oggetto aziendale ordini 308 dalle sorgenti dati 108 dal processo broker di oggetti 304. Analogamente, i dati nuovi e modificati provenienti dal modulo contatto clienti 310 e dal modulo elenco ordini 312 vengono inviati dall’oggetto aziendale clienti 306 e dall’oggetto aziendale ordini 308 alle sorgenti dati 108 dal processo broker di oggetti 304. Inoltre, il sevizio ruoli 323 può generare una definizione dell’oggetto ridotta sulla base delle definizioni dell’oggetto complete. Per esempio, il servizio ruoli 323 può recuperare un ruolo associato a un particolare utente e una pluralità di proprietà e/o metodi autorizzati associati a tale ruolo. Le proprietà e/o i metodi non autorizzati sono quindi rimossi dalla definizione dell’oggetto aziendale (per es. non è permesso a un utente di scrivere sull’oggetto aziendale clienti, quindi i metodi UpdateBalance e UpdateContact sono rimossi).
L’oggetto aziendale clienti di esempio 306 comprende una proprietà ID cliente, una proprietà nome, una proprietà indirizzo, una proprietà saldo scoperto, una proprietà carica saldo, una proprietà aggiorna saldo, una proprietà carica contatto e un metodo aggiorna contatto. La proprietà ID cliente nell’oggetto aziendale clienti 306 è connessa alla proprietà ID cliente nella sorgente dati ERP 314 e/o alla proprietà ID cliente nella sorgente dati CRM 316. La proprietà nome e la proprietà indirizzo nell’oggetto aziendale clienti 306 sono connesse alla proprietà nome e alla proprietà indirizzo nella sorgente dati CRM 316. La proprietà saldo scoperto nell’oggetto aziendale clienti 306 è connessa alla proprietà saldo scoperto nella sorgente dati ERP 314. Il metodo carica saldo e il metodo aggiorna saldo nell’oggetto aziendale clienti 306 sono connessi al metodo carica saldo e al metodo aggiorna saldo nella sorgente dati ERP 314. Il metodo carica contatto e il metodo aggiorna contatto nell’oggetto aziendale clienti 306 sono connessi al metodo carica contatto e al metodo aggiorna contatto nella sorgente dati CRM 316.
L’oggetto aziendale ordini di esempio 308 comprende una proprietà numero ordine, una proprietà ID cliente, una proprietà data consegna, una proprietà imposta, una proprietà totale, una proprietà stato, un metodo crea ordine, un metodo carica ordine, un metodo aggiorna ordine, un metodo cancella ordine, un metodo calcola sconto e un metodo calcola imposta. La proprietà numero ordine e la proprietà stato nell’oggetto aziendale ordini 308 sono connesse alla proprietà numero ordine e alla proprietà stato nella sorgente dati ERP 314. La proprietà ID cliente nell’oggetto aziendale ordini 308 è connessa alla proprietà ID cliente nella sorgente dati ERP 314 e/o alla proprietà ID cliente nella sorgente dati aggiuntiva 320. La proprietà data di consegna, la proprietà imposta e la proprietà totale nell’oggetto aziendale ordini 308 sono connesse alla proprietà data di consegna, alla proprietà imposta e alla proprietà totale nella sorgente dati aggiuntiva 320. Per creare il metodo ordine, il metodo carica ordine, il metodo aggiorna ordine e il metodo cancella ordine nell’oggetto aziendale ordini 308 sono connessi al metodo crea ordine, al metodo carica ordine, al metodo aggiorna ordine e al metodo cancella ordine nella sorgente dati ERP 314. Il metodo calcola sconto e il metodo calcola imposta nell’oggetto aziendale ordini 308 sono connessi al metodo calcola sconto e al metodo calcola imposta nella sorgente dati di funzioni 322. Si apprezzerà che i nomi delle proprietà e/o dei metodi nelle sorgenti dati 108 non devono necessariamente corrispondere ai nomi delle proprietà e/o dei metodi negli oggetti aziendali 306, 308.
Una vista più dettagliata della pagina ordini clienti 302 e le connessioni associate all’oggetto aziendale clienti 306 e all’oggetto aziendale ordini 308 sono illustrate in Fig. 5. In questo esempio, se l’utente preme un pulsante carica 502, il software di unione (binder) associato al processo modulo 326 richiama il metodo carica contatto dell’oggetto aziendale clienti 306 e il metodo carica ordine dell’oggetto aziendale ordini 308. Per la chiamata a entrambi i metodi, il processo modulo 326 fornisce il valore del campo numerico cliente 504 dal modulo contatto clienti 310. In alternativa, il processo modulo 326 può ottenere il valore del campo numerico cliente 504 dalla proprietà ID cliente dell’oggetto aziendale clienti 306 e/o dell’oggetto aziendale ordini 308. Queste connessioni logiche possono essere definite in qualsiasi maniera idonea. Per esempio, può essere utilizzata un’interfaccia grafica utente per permettere a un utente di tracciare linee di connessione tra i moduli 302, 310, 312 e rappresentazioni grafiche degli oggetti aziendali 306, 308. Preferibilmente, l’utente può progettare moduli utilizzando solo un browser web. Per esempio, può essere utilizzata un’interfaccia Java e XML (AJAX) asincrona.
Quando il processo modulo 326 richiama il metodo carica contatto dell’oggetto aziendale clienti 306 con il valore del campo numerico cliente 504 come parametro (per es. utilizzando AJAX), il processo broker di oggetti 304 traduce la chiamata al metodo nel linguaggio nativo della sorgente dati associata 108 e recupera i dati associati dalla sorgente dati 108 nel loro formato nativo. Nello specifico, il servizio broker CRM 330 invoca il metodo carica contatto nativo della sorgente dati CRM 316 e riceve indietro il nome e l’indirizzo del contatto dalla sorgente dati CRM 316. Il servizio broker CRM 330 quindi memorizza il nome e i dati di contatto nell’oggetto aziendale clienti 306. Per esempio, il servizio broker CRM 330 può essere codice ASP in esecuzione sul server per broker di oggetti 114 che invia un file XML (o un altro file standardizzato) al processo modulo 326, cioè codice JavaScript in esecuzione sul dispositivo client 102 che visualizza il modulo contatto clienti 310. Una volta che l’oggetto aziendale clienti 306 viene aggiornato con i nuovi dati di nome e indirizzo, il processo modulo 326 popola il campo nome 506 e il campo indirizzo 508 del modulo contatto clienti 310. Utilizzando questo metodo, un modulo HTML può essere aggiornato senza inviare l’intero modulo al server e rendere indietro l’intero modulo HTML.
Analogamente, quando il processo modulo 326 richiama il metodo carica ordine dell’oggetto aziendale ordini 308 con il valore del campo numerico cliente 504 come parametro, il processo broker di oggetti 304 traduce la chiamata al metodo nel linguaggio nativo della sorgente dati associata 108 e recupera i dati associati dalla sorgente dati 108 nel loro formato nativo. Nello specifico, il servizio broker ERP 328 invoca il metodo carica ordine nativo della sorgente dati ERP 314 e riceve indietro un elenco di numeri d’ordine, un elenco associato di totali e un elenco associato di stati dalla sorgente dati ERP 314. Per esempio, i dati possono essere restituiti in forma di tabella di database. Questi valori saranno infine utilizzati per compilare la colonna numero ordine 510, la colonna importo 512 e la colonna stato 514 della tabella ordini 516 nel modulo elenco ordini 312. Tuttavia, in questo esempio, la colonna data di consegna 518 non può essere fornita dalla sorgente dati ERP 314, poiché la sorgente dati ERP 314 non ha queste informazioni.
I dati data di consegna sono memorizzati nella sorgente dati aggiuntiva 320 (per es., il campo data di consegna è stato aggiunto in seguito dall’utente). Pertanto, quando il processo modulo 326 richiama il metodo carica ordine dell’oggetto aziendale ordini 308 con il valore del campo numerico cliente 504 come parametro, il servizio broker aggiuntivo 334 invoca il metodo carica data di consegna della sorgente dati aggiuntiva 320 e riceve indietro un elenco di date di consegna e numeri d’ordine associati dalla sorgente dati aggiuntiva 320. Il processo broker di oggetti 304 e/o il processo modulo 326 mette in correlazione le date di consegna con i dati di importo e i dati di stato ricevuti dalla sorgente dati ERP 314 utilizzando i dati di numero d’ordine che sono comuni a entrambi gli elenchi.
Il processo broker di oggetti 304 quindi memorizza l’elenco di numeri d’ordine, l’elenco associato di date di consegna, l’elenco associato di totali e l’elenco associato di stati sull’oggetto aziendale ordini 308. Per esempio, il servizio broker ERP 328, il servizio broker aggiuntivo 334 e/o altro software (per es. codice ASP in esecuzione sul server per broker di oggetti 114) può inviare un file XML (o un altro file standardizzato) al processo modulo 326 (per es. JavaScript in esecuzione sul dispositivo client 102). Una volta che l’oggetto aziendale ordini 308 è aggiornato con i nuovi dati, il processo modulo 326 popola la tabella ordini 516 nel modulo elenco ordini 312.
Un diagramma di flusso di un processo broker di oggetti di esempio 304 è illustrato in Fig. 6. Preferibilmente, il processo broker di oggetti 304 è integrato in uno o più programmi software che sono memorizzati in una o più memorie ed eseguiti da uno o più processori. Per esempio, il processo broker di oggetti 304 può essere codice ASP (o qualsiasi altro tipo di software) in esecuzione sul server per broker di oggetti 114. Sebbene il processo broker di oggetti 304 sia descritto con riferimento al diagramma di flusso illustrato in Fig. 6, si apprezzerà che possono essere utilizzati anche molti altri metodi per eseguire le operazioni associate al processo broker di oggetti 304. Per esempio, l’ordine di molti dei passaggi può essere modificato e alcuni dei passaggi descritti possono essere facoltativi.
Generalmente, il processo broker di oggetti 304 riceve chiamate ai metodi standardizzate dal processo modulo 326 e converte le chiamate ai metodi standardizzate in chiamate ai metodi native. Il processo broker di oggetti 304 quindi invia le chiamate ai metodi native alla(e) sorgente(i) dati associata(e) 108 e riceve una o più risposte native dalla(e) sorgente(i) dati 108. Il processo broker di oggetti 304 quindi converte la(e) risposta(e) nativa(e) in risposta(e) standardizzata(e) e invia la(e) risposta(e) standardizzata(e) al processo modulo chiamante 326.
Più specificamente, il processo broker di oggetti 304 riceve una chiamata al metodo dal processo modulo 326 utilizzando un protocollo standardizzato (blocco 602). La chiamata al metodo standardizzata è associata a un oggetto aziendale e comprende qualsiasi valore di proprietà (cioè parametro) necessario per questo metodo. Per esempio, può essere che un dispositivo client 102 stia visualizzando la pagina ordini clienti 302 come documento HTML. Utilizzando un trigger di eventi onBlur, il dispositivo client 102 può eseguire codice JavaScript per inviare un file XML 604 che rappresenta “LoadContact(1234567)” su Internet 116 tramite una richiesta HTTP a uno script ASP in esecuzione sul server per broker di oggetti 114. Si apprezzerà che può essere utilizzato qualsiasi protocollo idoneo anziché HTML, JavaScript, XML, HTTP e/o ASP. Per esempio, può essere utilizzato VBScript anziché JavaScript, e Perl anziché ASP.
La richiesta XML di esempio 604 comprende la chiamata al metodo “LoadContact” 606 delimitata da un tag “Method” di apertura 608 e un tag “Method” di chiusura 610. Inoltre, la richiesta XML di esempio 604 comprende il valore di proprietà “CustomerlD” 612 delimitato da un tag “CustomerlD” di apertura 614 e un tag “CustomerlD” di chiusura 616.
Il processo broker di oggetti 304 quindi passa la chiamata al metodo standardizzata al servizio broker associato alla chiamata al metodo (blocco 618). Per esempio, il processo broker di oggetti 304 può inviare il file XML 604 contenente la chiamata al metodo LoadContact 606 al servizio broker CRM 330.
Il servizio broker associato alla chiamata al metodo quindi traduce la chiamata al metodo dal protocollo standardizzato al protocollo nativo per la sorgente dati associata 108 (blocco 620). Per esempio, il servizio broker CRM 330 può formare una richiesta nativa 622 per la sorgente dati CRM 316 dal file XML ricevuto 604. La richiesta nativa 622 può utilizzare qualsiasi protocollo. Per esempio, la richiesta nativa 622 può essere un’interrogazione SQL che sa che la sorgente dati CRM 316 tiene i dati di contatto clienti in un campo “FullName” 624 e un campo “HomeAddress” 626 di una “ContactsTable” 628 indicizzata da un campo “CustNum” 630.
Il servizio broker associato alla chiamata al metodo quindi invia l’interrogazione nativa alla sorgente dati associata 108 e riceve una risposta nativa dalla sorgente dati 108 (blocco 632). Per esempio, il servizio broker CRM 330 può essere uno script ASP in esecuzione sul server per broker di oggetti 114 che invia la richiesta nativa 622 alla sorgente dati CRM 316 come interrogazione SQL e riceve una risposta nativa 634 in forma di elenco delimitato da virgole. In questo esempio, la risposta nativa 634 comprende il valore nome 634 e il valore indirizzo 636 del contatto associato al valore di proprietà “CustomerlD” 612.
Il servizio broker quindi riconverte la risposta nativa nel protocollo standardizzato (blocco 638). Per esempio, il servizio broker CRM 330 può attendere una risposta SQL dalla sorgente dati CRM 316 e generare una risposta XML associata 640. In questo esempio, la risposta XML 640 comprende tutte le informazioni provenienti dalla richiesta XML originale 604 (cioè la chiamata al metodo “LoadContact” 606 delimitata da un tag “Method” di apertura 608 e un tag “Method” di chiusura 610 e il valore di proprietà “CustomerlD” 612 delimitato da un tag “CustomerlD” di apertura 614 e un tag “CustomerlD” di chiusura 616). Inoltre, la risposta XML 640 comprende il valore nome 634 delimitato da un tag “Name” di apertura 642 e un tag “Name” di chiusura 644, nonché il valore indirizzo 640 delimitato da un tag “Address” di apertura 646 e un tag “Address” di chiusura 648.
Il servizio broker quindi invia la risposta standardizzata alla funzione chiamante nel processo modulo 326 (blocco 646). Per esempio, il servizio broker CRM 330 può inviare la risposta XML 640 a un JavaScript associato alla pagina ordini clienti 302 su un dispositivo client 102. Come descritto nel seguito, il processo modulo 326 può quindi utilizzare la risposta XML 640 per popolare la pagina ordini clienti basata su HTML 302.
Un diagramma di flusso di un processo modulo di esempio 326 è illustrato in Fig. 7. Preferibilmente, il processo modulo 326 è integrato in uno o più programmi software che sono memorizzati in una o più memorie ed eseguiti da uno o più processori. Per esempio, il processo modulo 326 può essere codice JavaScript (o qualsiasi altro tipo di software) in esecuzione su un dispositivo client 102. Sebbene il processo modulo 326 sia descritto con riferimento al diagramma di flusso illustrato in Fig. 7, si apprezzerà che possono essere utilizzati molti altri metodi per eseguire le operazioni associate al processo modulo 326. Per esempio, l’ordine di molti dei passaggi può essere modificato, e alcuni dei passaggi descritti possono essere facoltativi.
Generalmente, il processo modulo 326 rileva eventi associati a un modulo (per es. la pagina ordini clienti HTML 302) e invia chiamate ai metodi standardizzate (per es. la richiesta XML 604) al processo broker di oggetti 304. Quando il processo modulo 326 riceve indietro la(e) risposta(e) standardizzata(e) (per es. la risposta XML 640) dal processo broker di oggetti 304, il processo modulo 326 può utilizzare la(e) risposta(e) standardizzata(e) per popolare il modulo (per es. la pagina ordini clienti HTML 302).
Più specificamente, il processo modulo 326 rileva un evento che richiede l’aggiornamento di un modulo e/o una pagina (blocco 702). Per esempio, il processo modulo 326 può essere codice JavaScript in esecuzione su un dispositivo client 102 in associazione con la pagina ordini clienti 302.
Quando un utente preme il pulsante carica 502 sul modulo contatto clienti 310, il processo modulo 326 rileva l’evento onClick associato al pulsante carica 502 ed esegue una porzione del codice JavaScript associato a tale evento onClick (cioè il gestore di eventi).
Quando è eseguito il gestore di eventi, il processo modulo 326 genera una chiamata al metodo idonea nel protocollo standard (blocco 704). Per esempio, il dispositivo client 102 può eseguire codice JavaScript per generare il file XML 604 che rappresenta “LoadContact(1234567)”. Come descritto in precedenza, la richiesta XML di esempio 604 comprende la chiamata al metodo “LoadContact” 606 delimitata da un tag “Method” di apertura 608 e un tag “Method” di chiusura 610. Inoltre, la richiesta XML di esempio 604 comprende il valore di proprietà “CustomerlD” 612 delimitato da un tag “CustomerlD” di apertura 614 e un tag “CustomerlD” di chiusura 616.
Il processo modulo 326 quindi invia la chiamata al metodo standardizzata al processo broker di oggetti 304 (blocco 706). Per esempio, il dispositivo client 102 può inviare la richiesta XML 604 su Internet 116 tramite una richiesta HTTP a uno script ASP in esecuzione sul server per broker di oggetti 114. Il processo broker di oggetti 304 quindi comunica con le sorgenti dati associate 108 utilizzando i protocolli nativi e invia al processo modulo 326 una risposta standardizzata (blocco 708). Per esempio, il JavaScript sul lato client associato al processo modulo 326 può ricevere la risposta XML 640 dallo script ASP del lato server associato al processo broker di oggetti 304.
Come descritto in precedenza, la risposta XML di esempio 640 comprende tutte le informazioni provenienti dalla richiesta XML originale 604 (cioè la chiamata al metodo “LoadContact” 606 delimitata da un tag “Method” di apertura 608 e un tag “Method” di chiusura 610 e il valore di proprietà “CustomerlD” 612 delimitato da un tag “CustomerlD” di apertura 614 e un tag “CustomerlD” di chiusura 616). Inoltre, la risposta XML 640 comprende il valore nome 634 delimitato da un tag “Name” di apertura 642 e un tag “Name” di chiusura 644, nonché il valore indirizzo 640 delimitato da un tag “Address” di apertura 646 e un tag “Address” di chiusura 648. Il processo modulo 326 può quindi utilizzare la risposta standardizzata per popolare il modulo del cliente (blocco 710). Per esempio, il JavaScript sul lato client può popolare il campo nome 506 e il campo indirizzo 508 del modulo contatto clienti basato su HTML 310.
Uno strumento di progettazione di workflow 800 che permette a un utente di definire una mappa di risorse 802 è illustrato in Fig. 8. In questo esempio, lo strumento di progettazione di workflow 800 comprende una sezione di esplorazione file 804 e un canvas di progettazione 806. La sezione di esplorazione file 804 permette all’utente di trovare e organizzare una pluralità di file associati al workflow. Il canvas di progettazione 806 permette all’utente di tracciare una rappresentazione grafica della mappa di risorse 802. In questo esempio, viene mostrata una mappa di risorse 802 che comprende un oggetto staff 808 e un oggetto cliente 810. L’oggetto staff 808 e l’oggetto cliente 810 comprendono ciascuno uno o più nodi di input 812 e uno o più nodi di output 814. I nodi di input 812 sono connessi ai nodi di output 814 mediante frecce di processo 816. In questo esempio, un processo supporto 816a e un processo vendite 816b escono ciascuno dall’oggetto staff 808 ed entrano nell’oggetto cliente 810. Analogamente, un processo ordine 816c esce dall’oggetto cliente 810 ed entra nell’oggetto staff 808.
Definendo i workflow in termini di risorse note (per es. l’oggetto staff 808 e l’oggetto cliente 810) e di interazioni tra tali risorse (per es. l’oggetto cliente 810 necessita di supporto da parte dell’oggetto staff 808), il progettista di workflow può individuare e progettare ciascun processo iniziando da un livello elevato e procedendo con analisi più dettagliate fino ai processi sottostanti e ai workflow automatizzati.
La mappa di risorse 802 permette anche all’ereditarietà degli oggetti aziendali di mostrare le classi di un oggetto aziendale e gli oggetti figlio di quel particolare oggetto aziendale. Gli oggetti figlio possono essere associati a oggetti padre modificando le proprietà associate all’oggetto padre e/o aggiungendo proprietà all’oggetto padre. Una singola combinazione di oggetti padre/figlio potrebbe avere una definizione di link esclusiva all’interno di un’altra risorsa sul canvas. Per esempio, l’oggetto cliente padre 810 può comprendere un oggetto figlio cliente istituzionale e un oggetto figlio cliente commerciale. Il processo vendite 816b tra l’oggetto staff 808 e l’oggetto cliente 810 può essere diverso a seconda del tipo di oggetto cliente 810 (cioè un processo vendite 816b per i clienti istituzionali 810 e un altro processo vendite per i clienti commerciali 810). Analogamente, l’oggetto staff 808 può essere un oggetto padre con staff di vendita e staff di supporto come due risorse figlio.
Un’altra vista dello strumento di progettazione di workflow 800 è illustrata in Fig. 9. In questa vista, lo strumento di progettazione di workflow 800 è utilizzata per creare una mappa di processi 902. In questo esempio, viene definito il processo supporto 816a. Il processo supporto di esempio 816a comprende un passaggio di avvio 904, un passaggio respinto 906 e un passaggio approvato 908. In questo esempio, deve essere eseguito soltanto uno di questi passaggi 904, 906, 908. Pertanto, sarà inserito un nuovo passaggio 910 per selezionare uno dei tre passaggi 904, 906 e 908. Il nuovo passaggio 910 comprende una pluralità di azioni 912 e una pluralità di nodi di output corrispondenti 814. In questo esempio, il nuovo passaggio 910 comprende un’azione approva 914, un’azione respingi 916 e un’azione ridireziona 918. L’utente connette il nodo di output respinto 814a al nodo di input 812a del passaggio respinto 906 trascinando il connettore di processo 816d. La logica di linea associata viene automaticamente configurata per l’utente.
Un’altra mappa di processi 1000 è illustrata in Fig. 10. In questa mappa di processi di esempio 1000, è evidenziata una porzione 1002 della mappa di processi 1000. Nello specifico, un passaggio approvato 1004 e un passaggio di notifica 1006 sono inclusi in una porzione evidenziata 1002. Questa porzione 1002 può definire una regione localizzata della mappa di processi 1000 mentre altre porzioni della mappa di processi 1000 (per es. il resto della mappa di processi 1000 in questo esempio) sono considerate regioni globali. Utilizzando l’ereditarietà dei processi, questa localizzazione di particolari regioni di processi permette a un titolare di processi di mantenere il controllo del processo globale e al tempo stesso permettere ad altri utenti di personalizzare particolari porzioni 1002. Per esempio, il processo globale può stabilire quando qualcosa è approvato e dove è inoltrata la notifica, ma un singolo ufficio di un’organizzazione può compiere una singola serie di azioni in risposta all’approvazione e un altro ufficio dell’organizzazione può compiere un’altra serie di azioni in risposta all’approvazione. I processi locali possono persino comprendere passaggi di processo aggiuntivi che sono specifici della regione localizzata. Il processo 1000 è mantenuto sotto una singola definizione di processo, in modo che le modifiche apportate alla porzione globale siano automaticamente applicate a tutte le istanze del processo 1000 e le modifiche apportate alla porzione locale 1002 siano applicate soltanto alle località associate.
Inoltre, i singoli passaggi di processo e/o le porzioni 1002 possono essere bloccati. In questo esempio, un passaggio di approvazione 1008 è singolarmente bloccato e anche la porzione locale 1002 è bloccata. Ogni passaggio bloccato e ogni porzione bloccata comprende un’icona di blocco 1010 per indicare uno stato di blocco. Bloccando un passaggio di processo 1008 e/o una porzione di processo 1002, i progettisti dei processi possono limitare la capacità di un altro utente di modificare particolari impostazioni di configurazione, aggiungere o rimuovere dipendenze ecc. dalla logica definita e bloccata. Gli attributi di bloccaggio possono essere manipolati anche da guide e template in maniera programmatica, permettendo a blocchi costruttivi di livello inferiore di nascondere o bloccare la loro logica di implementazione.
Un framework collaborativo permette a qualsiasi progettista di processi che lavori nell’ambito dello strumento di progettazione di workflow 800 di condividere visivamente il proprio canvas di progettazione 806 con un altro utente attraverso la rete 116. Un progettista di processi può anche intraprendere una conversazione vocale o testuale con le altre parti per discutere del processo in corso di progettazione. In questo modo, il progettista di processi può coinvolgere altri utenti nella progettazione dei processi utilizzando strumenti di condivisione delle applicazioni e collaborazione. Per esempio, facendo clic destro sul canvas di progettazione 806, il progettista di processi può contattare un particolare individuo presso l’ufficio contabilità per chiedergli a chi occorra notificare l’approvazione di un acquisto. Messaggi di testo e/o registrazioni vocali tra collaboratori possono essere anche salvati in un database per essere riesaminati in un secondo momento. Per esempio, quando un processo è in corso di valutazione per la riprogettazione, il progettista di processi può ascoltare una conversazione di collaborazione per stabilire perché un particolare passaggio è stato eseguito in quel modo.
Ogni passaggio della rappresentazione grafica del processo preferibilmente comprende una striscia di attività. Una striscia di attività di esempio 1100 è illustrata in Fig. 11. In questo esempio, la striscia di attività 1100 comprende una o più icone di eventi 1002 che rappresentano gli eventi associati al passaggio del processo. Per esempio, l’utente può trascinare un evento invia email in un passaggio del processo. In una simile istanza, un’icona di evento email 1104 viene aggiunta alla striscia di attività 1100. Se il numero di icone di evento 1102 supera l’ampiezza della striscia di attività 1100, l’utente può scorrere tra le icone di eventi utilizzando i pulsanti freccia 1106.
Quando è selezionata una particolare icona di evento 1102, all’utente appare un wizard di configurazione per configurare quella porzione di processo. Preferibilmente, ogni passaggio di un processo viene presentato all’utente sotto forma di un cubo e il wizard di configurazione viene ruotato nella visualizzazione per creare l’effetto di una singola entità su cui sta lavorando l’utente. Per esempio, quando un utente preme l’icona di evento e-mail 1104, la striscia di attività 1100 ruota in un wizard di configurazione di evento e-mail 1200. Una vista in rotazione parziale di un wizard di configurazione di evento e-mail di esempio 1200 è illustrata in Fig. 12. Una vista in rotazione totale dello stesso wizard di configurazione 1200 è illustrata in Fig. 13. Il wizard di configurazione e-mail 1200 può essere utilizzato per progettare e-mail costruite dinamicamente utilizzate da uno o più processi workflow. Per esempio, il passaggio di notifica 1006 del processo approvazione 1000 illustrato in Fig. 10 comprende un output 814 che può essere un messaggio e-mail automatico. Il wizard di configurazione e-mail 1200 può essere utilizzato per progettare in che modo è costruito il messaggio e-mail.
Il wizard di configurazione e-mail può utilizzare un wizard di riferimento, che permette a un utente di utilizzare un processo mentre sta progettando un altro processo. Per esempio, un wizard di riferimento può permettere a un utente di chiamare qualsiasi metodo in qualsiasi assembly .NET, servizio Web o servizio WCF nell’ambito della progettazione di un processo.
Preferibilmente, il wizard di configurazione 1200 comprende una porzione di visualizzazione principale 1202 e un pulsante avanti 1204. La porzione di visualizzazione principale 1202 visualizza una sola pagina del wizard di configurazione 1200. Il pulsante avanti 1204 fa avanzare la porzione di visualizzazione principale 1202 alla pagina successiva del wizard di configurazione 1200. Un pulsante indietro (non illustrato) modifica la porzione di visualizzazione principale 1202 per la visualizzazione della pagina precedente del wizard di configurazione 1200.
Il wizard di configurazione 1200 comprende anche una palette di pagine 1206. La palette di pagine 1206 comprende una pluralità di indici da 1208 a 1220. Ognuno degli indici da 1208 a 1220 rappresenta una delle pagina del wizard di configurazione 1200. L’utente può rapidamente saltare a qualsiasi pagina del wizard di configurazione 1200 facendo clic sull’indice associato. Quando un utente salta a una particolare pagina del wizard di configurazione 1200, la porzione di visualizzazione principale 1202 viene ridisegnata per rispecchiare tale pagina.
Inoltre, l’utente può rapidamente visualizzare una finestra a comparsa di qualsiasi pagina del wizard di configurazione 1200 senza saltare a quella pagina (cioè senza disegnare il contenuto della pagina nella porzione di visualizzazione principale 1202) tenendo il cursore sopra l’indice associato. Per esempio, la terza pagina 1212 del wizard di configurazione e-mail di esempio 1200 è visualizzata come una finestra a comparsa nella Fig. 14. In questo esempio, la terza pagina 1212 del wizard di configurazione 1200 comprende una casella di input oggetto 1402 e una casella di input corpo 1404. La casella di input oggetto 1402 del wizard di configurazione e-mail 1200 è utilizzata per definire la riga oggetto dell’e-mail automatica. La casella di input corpo 1404 del wizard di configurazione e-mail 1200 è utilizzata per definire il corpo dell’e-mail automatica. Qualsiasi valore immesso in una pagina del wizard di configurazione del processo 1200 è visibile nella finestra a comparsa. Per esempio, se l’utente avesse immesso “Approval Report” nella casella di input oggetto 1402 della terza pagina 1212 del wizard di configurazione e-mail 1200, comparirebbe “Approval Report” nella casella di input oggetto 1402 della finestra a comparsa. In questo modo, l’utente può immettere valori su diverse pagine del wizard di configurazione 1200 in maniera coerente con altre voci immesse, senza necessità di ricordare tali altri voci e/o uscire dalla pagina corrente.
Un diagramma di flusso di un processo wizard di configurazione di esempio 1500 è illustrato in Fig. 15. Preferibilmente, il processo wizard di configurazione 1500 è integrato in uno o più programmi software che sono memorizzati in una o più memorie ed eseguiti da uno o più processori. Sebbene il processo wizard di configurazione 1500 sia descritto con riferimento al diagramma di flusso illustrato in Fig. 15, si apprezzerà che possono essere utilizzati molti altri metodi per eseguire le operazioni associate al processo wizard di configurazione 1500. Per esempio, l’ordine di molti dei passaggi può essere modificato e alcuni dei passaggi descritti possono essere facoltativi.
Il processo 1500 inizia quando un dispositivo client 102 rileva un evento associato a una rappresentazione grafica di un passaggio di processo 1008 (blocco 1502). Per esempio, l’utente può cliccare su un pulsante di configurazione nella striscia di attività 1100. In risposta, il dispositivo client 102 induce la visualizzazione di una sequenza animata (blocco 1504). Per esempio, il dispositivo client può visualizzare la striscia di attività in rotazione in tre dimensioni per mostrare un “lato” del cubo del wizard di configurazione e-mail. In questo modo, l’utente ottiene un riscontro visivo del fatto che i due oggetti (per es. la striscia di attività 1100 e il wizard di configurazione e-mail 1200) sono correlati.
Il wizard di configurazione comprende una pluralità di pagine di configurazione in una palette di indici 1206 e una pagina di configurazione corrente in una porzione di visualizzazione principale 1202 (blocco 1506). Per esempio, la prima pagina di un wizard di configurazione e-mail può chiedere all’utente di immettere l’indirizzo e-mail del destinatario e l’oggetto del messaggio e-mail. Mentre il dispositivo client 102 sta visualizzando le pagine del wizard di configurazione e ricevendo informazioni sulla configurazione dall’utente, il dispositivo client 102 cerca anche una pluralità di eventi come movimenti del mouse e clic del mouse.
Se viene rilevato un primo tipo di evento associato a una delle immagini d’indice 1208-1220 (blocco 1508), il dispositivo client 102 preferibilmente visualizza una versione più ampia dell’immagine d’indice associata (blocco 1510). Per esempio, se l’utente muove il cursore del mouse su una particolare immagine d’indice 1208-1220, può essere visualizzata una finestra a comparsa 1212 che mostra una versione più ampia di quell’immagine d’indice. Preferibilmente, la versione più ampia dell’immagine d’indice è una finestra separata 1212 che è più piccola della porzione di visualizzazione principale 1202 (vedere Fig. 14). Tuttavia, può essere utilizzato qualsiasi tipo di immagine idonea. Per esempio, la versione più ampia dell’immagine d’indice può “temporaneamente” sostituire la porzione di visualizzazione principale 1202.
Se viene rilevato un secondo tipo di evento associato a una delle immagini d’indice 1208-1220 (blocco 1512), il dispositivo client 102 preferibilmente rimuove la versione più ampia dell’immagine d’indice associata (blocco 1514). Per esempio, se l’utente sposta il cursore del mouse fuori da una particolare immagine d’indice, la finestra a comparsa che mostra la versione più ampia di quell’immagine d’indice può essere rimossa. Se la versione più ampia dell’immagine d’indice è una finestra separata, quella finestra viene rimossa dal display e il contenuto “sotto” la finestra rimossa viene ridisegnato. Se la versione più ampia dell’immagine d’indice ha sostituito la porzione di visualizzazione principale 1202, allora il contenuto precedente della porzione di visualizzazione principale 1202 (per es. la pagina di configurazione corrente) viene ridisegnato nella porzione di visualizzazione principale 1202.
La versione più ampia dell’immagine d’indice mostra anche qualsiasi informazione di configurazione precedentemente immessa dall’utente. Per esempio, se l’utente ha immesso l’indirizzo e-mail dei destinatari nella prima pagina del wizard di configurazione, si è spostato in un’altra pagina del wizard di configurazione e poi da deciso di richiamare l’indirizzo e-mail immesso senza scorrere indietro del tutto fino alla prima pagina, l’utente può semplicemente far scorrere il mouse sopra il primo indice per richiamare le informazioni immesse.
Se viene rilevato un terzo tipo di evento associato a una delle immagini d’indice 1208-1220 (blocco 1516), il dispositivo client 102 preferibilmente sostituisce l’immagine del display principale con una versione a grandezza naturale dell’immagine d’indice associata (blocco 1518). Per esempio, se l’utente clicca con il mouse su una particolare immagine d’indice, la porzione di visualizzazione principale 1202 preferibilmente salta a quella pagina nel wizard di configurazione. A differenza dell’esempio con il mouse che scorre sopra, rimuovendo il mouse dall’indice non si riporta la porzione di visualizzazione principale 1202 alla pagina precedente (cioè l’utente si sposta in quella pagina di configurazione anziché rivisualizzare temporaneamente quella pagina di configurazione.
In qualsiasi momento, l’utente può immettere una o più opzioni di configurazione (blocco 1520) e le opzioni di configurazione vengono memorizzate (blocco 1522). Se l’utente esce dal wizard di configurazione (blocco 1524), il processo 1508-1520 di controllo per la ricerca di azioni dell’utente e opzioni di configurazione si ripete.
Anche se l’oggetto aziendale dinamico può essere uno strumento utile nelle attuali organizzazioni, una volta che un oggetto aziendale è stato creato, non è facile per i dispositivi client remoti accedervi e consumarlo. Alcune delle tecnologie esistenti richiedono che sia definito un endpoint prima che l’oggetto aziendale possa essere consumato attraverso le tecnologie dei servizi web esistenti. Un endpoint è utilizzato per specificare i requisiti di interazione tra il dispositivo client e l’oggetto aziendale. Per esempio, il dispositivo client invia un messaggio all’endpoint dell’oggetto aziendale quando vuole utilizzare l’oggetto aziendale, e il messaggio viene formattato secondo le informazioni specificate dall’endpoint. Un oggetto aziendale può avere molteplici endpoint che consentono ai clienti di consumare tale oggetto aziendale in diversi modi. Altre tecnologie esistenti possono fornire un endpoint predefinito dove l’utente non può configurare nessuno dei parametri o delle impostazioni dell’endpoint.
Tipicamente, un endpoint è definito da un indirizzo, un legame (binding) e un contratto. Un indirizzo è la locazione in cui risiede l’endpoint. Un binding specifica in che modo un oggetto aziendale può essere consumato, per esempio informazioni di codifica o protocollo. Un contratto per ogni oggetto elenca le operazioni esposte dall’oggetto aziendale. Tutte queste informazioni devono essere specificate prima che un oggetto aziendale possa essere utilizzato da un dispositivo client remoto.
Gli approcci attualmente esistenti presentano diversi problemi. In alcuni casi, il contratto deve essere generato manualmente per ogni oggetto.
Poiché l’endpoint comprende il contratto, anche l’endpoint è generato manualmente per ogni oggetto. La generazione manuale di un contratto (e quindi dell’endpoint) può essere dispendiosa in termini di costi e di tempo ed è suscettibile di errore da parte dell’utente. Inoltre, l’endpoint può divenire obsoleto se non viene aggiornato non appena si aggiorna l’oggetto aziendale e può succedere che l’utente faccia affidamento su informazioni dell’endpoint che non rappresentano in maniera accurata l’oggetto aziendale.
Il presente sistema rende disponibili oggetti aziendali a client attraverso endpoint, dove gli endpoint sono generati dinamicamente. Pertanto, non vi è necessità di generare manualmente un endpoint. Gli endpoint possono essere memorizzati su un server. Gli endpoint associati agli oggetti vengono generati automaticamente nel momento in cui vengono creati oggetti aziendali, oppure gli endpoint possono essere creati nel momento in cui è richiesto l’oggetto aziendale. In una forma realizzativa, gli endpoint sono generati in base a criteri di configurazione che permettono all’utente di applicare vari livelli di isolamento agli endpoint come spiegato nel seguito. Che siano utilizzati o meno criteri di configurazione, non vi è necessità di generare manualmente le informazioni dell’endpoint poiché l’endpoint viene generato automaticamente nel momento in cui l’oggetto aziendale viene richiesto da un dispositivo client o creato. I dispositivi client possono comunicare con l’endpoint dinamico e utilizzare contratti associati agli oggetti aziendali come se i contratti fossero stati generati automaticamente. Le proprietà dell’oggetto aziendale possono essere esposte attraverso contratti di dati e i metodi dell’oggetto aziendale possono essere esposti attraverso contratti di operazioni.
Il presente sistema libera risorse e migliora l’efficienza poiché consente di progettare, implementare e consumare nuovi oggetti senza necessità di generare endpoint. I dispositivi client sono richiesti soltanto per conoscere e connettersi all’endpoint dinamico. I dispositivi client possono quindi utilizzare oggetti senza alcuna generazione, costruzione o pubblicazione di contratto come requisito essenziale. Le informazioni dell’endpoint, come un contratto, vengono generate dallo stesso servizio che ha creato gli oggetti aziendali. Pertanto, le informazioni dell’endpoint sono complete e compatibili con l’oggetto aziendale e non richiedono alcun coinvolgimento ulteriore di un programmatore o di strumenti di programmazione. Inoltre, poiché l’endpoint viene generato nel momento in cui l’oggetto aziendale è creato o richiesto, l’endpoint può permettere l’integrazione in nuovi ambienti che non esistevano quando l’oggetto aziendale è stato progettato.
In una forma realizzativa, un oggetto aziendale può essere periodicamente aggiornato per creare nuove versioni. Con contratti statici, ogni nuova versione dell’oggetto aziendale richiederebbe l’aggiornamento del contratto sul server per far sì che i client possano consumare l’oggetto aziendale. Altrimenti, il contratto (o le informazioni dell’endpoint) diventano obsolete e il client non dispone più del contratto più recente o accurato per consumare l’oggetto aziendale. Questo problema viene evitato nel presente sistema attraverso l’uso di contratti che sono generati dinamicamente. Poiché il presente sistema utilizza contratti dinamici, il contratto non è mai obsoleto. Se gli oggetti aziendali sono modificati, il contratto viene automaticamente modificato o aggiornato. Il dispositivo client o il consumatore continua a rivolgersi alla singola entità nota – l’endpoint dinamico – e l’endpoint dinamico mantiene le informazioni e le conoscenze sugli oggetti aziendali, sui processi e sulle risorse del sistema. L’endpoint dinamico continua a generare contratti per gli altri oggetti del sistema anche quando sono aggiuntivi nuovi oggetti o sono modificati oggetti esistenti.
In una forma realizzativa, le precedenti versioni degli endpoint sono mantenute anche quando vengono generati nuovi endpoint. Questo può essere utile quando un dispositivo client sceglie o richiede di utilizzare una versione specifica di un contratto o un endpoint, anche dopo che è stato generato un nuovo contratto o endpoint.
In una forma realizzativa, il server costruisce e pubblica contratti per tutti gli oggetti che sono mantenuti o memorizzati sul server. In una forma realizzativa, il server costruisce e pubblica contratti solo per un sottoinsieme di oggetti aziendali memorizzati sul server, con l’esclusione di alcuni oggetti aziendali. Il sottoinsieme può essere determinato sulla base di criteri di configurazione.
In alternativa, i criteri possono essere determinati nel momento stesso in cui il server costruisce e pubblica i contratti. Questo permette a un utente di esercitare un controllo granulare sulla natura dinamica del sistema.
Per esempio, il generatore di endpoint dinamici può implementare un sistema di categorie. In una forma realizzativa, ogni oggetto ha un proprio endpoint. In una forma realizzativa, ogni oggetto aziendale è collocato in una categoria, e ogni categoria ha un proprio endpoint. Quando molteplici oggetti aziendali condividono la stessa categoria (e quindi lo stesso endpoint), tali oggetti aziendali possono essere selezionati o deselezionati dal generatore di endpoint dinamici. Questo permette a un utente di aggiornare dinamicamente solo particolari categorie di oggetti aziendali.
Per esempio, un utente che lavora su un progetto può collocare tutti gli oggetti aziendali relativi a tale progetto in una categoria. L’utente può soltanto selezionare quella categoria (e quindi endpoint) e il generatore di endpoint dinamici aggiornerà in maniera dinamica i contratti per gli oggetti aziendali appartenenti a quella categoria. Gli altri oggetti aziendali di altre categorie vengono esclusi dal generatore di endpoint dinamici, riducendo il numero di oggetti aziendali che vengono aggiornati dinamicamente e quindi riducendo l’utilizzo di memoria, il tempo di rigenerazione e il tempo di avviamento. Gli utenti possono creare sottocategorie e scegliere di generare dinamicamente contratti per oggetti appartenenti a particolari sottocategorie. Pertanto, gli utenti possono controllare con precisione quali oggetti aziendali devono essere aggiornati dinamicamente.
La Fig. 16 è una schermata di una forma realizzativa di un sistema 1600 che implementa un Generatore di Endpoint Dinamici 1602 per permettere a un’Applicazione per Oggetti Aziendali 1604 di consumare oggetti aziendali. Vari oggetti aziendali sono memorizzati su un Server per Oggetti aziendali 1606. Per esempio, il Server per Oggetti Aziendali 1606 contiene un Oggetto Aziendale Clienti 1608, un Oggetto Aziendale Regione 1610, un Oggetto Aziendale Prodotti 1612, un Oggetto Aziendale Dipendenti 1614 e altri Oggetti Aziendali 1616. Gli oggetti aziendali comunicano con la Sorgente Dati per gli Oggetti Aziendali 1618. In una forma realizzativa, il sistema genera un endpoint nel momento in cui viene creato l’oggetto aziendale.
In una forma realizzativa, il sistema non ha generato alcun contratto per alcun oggetto aziendale, e genera endpoint solo nel momento in cui vengono richiesti gli oggetti aziendali. Per esempio, un’organizzazione può avere necessità di memorizzare il nome, il cognome e il numero di previdenza sociale dei propri clienti. Un utente specifica questi campi nel momento in cui definisce l’Oggetto Aziendale Clienti 1608.
L’Applicazione per Oggetti Aziendali 1604 può avere necessità di interagire con l’Oggetto Aziendale Clienti 1608. Per esempio, l’Applicazione per Oggetti Aziendali 1604 desidera creare un nuovo cliente utilizzando l’Oggetto Aziendale Clienti 1608. Tuttavia, l’Applicazione per Oggetti Aziendali 1604 non dispone delle informazioni dell’endpoint per l’Oggetto Aziendale Clienti 1608. Quando l’Applicazione per Oggetti Aziendali 1604 richiede di comunicare o desidera consumare l’Oggetto Aziendale Clienti 1608, essa invia una richiesta al Generatore di Endpoint Dinamici 1602. Il Generatore di Endpoint Dinamici 1602 automaticamente costruisce e pubblica le informazioni dell’endpoint, compreso un contratto di dati, per l’Oggetto Aziendale Clienti 1608. L’Applicazione per Oggetti Aziendali 1604 può così consumare l’Oggetto Aziendale Clienti 1608 anche se l’Oggetto Aziendale Clienti 1608 non aveva precedentemente un endpoint. In una forma realizzativa, il Generatore di Endpoint Dinamici 1602 genera un endpoint nel momento in cui viene creato un oggetto aziendale.
In una forma realizzativa, dopo che l’Applicazione per Oggetti Aziendali 1604 ha consumato l’Oggetto Aziendale Clienti 1608, la definizione dell’Oggetto Aziendale Clienti 1608 viene modificata. Per esempio, l’organizzazione può ora richiedere di memorizzare l’indirizzo dei propri clienti in aggiunta al nome, al cognome e al numero di previdenza sociale dei propri clienti. Le informazioni d’indirizzo possono essere recuperate da un database diverso dai database che detengono il nome, il cognome e il numero di previdenza sociale. Un utente modifica la definizione dell’Oggetto Aziendale Clienti 1608. Quando l’Oggetto Aziendale Clienti 1608 è aggiornato, la nuova proprietà dell’Oggetto Aziendale Clienti 1608 viene ripubblicata e il Generatore di Endpoint Dinamici 1602 riceve automaticamente notifica della modifica apportata all’Oggetto Aziendale Clienti 1608. Il Generatore di Endpoint Dinamici 1602 aggiorna le proprie informazioni e pubblica un endpoint aggiornato per l’Oggetto Aziendale Clienti 1608. In tal modo, l’Applicazione per Oggetti Aziendali 1604 dispone sempre delle informazioni dell’endpoint più aggiornate per l’Oggetto Aziendale Clienti 1608.
In una forma realizzativa, gli oggetti aziendali sono esposti a un dispositivo client attraverso un’infrastruttura web come la Windows Communication Foundation (WCF), che fa parte del framework .NET. Il dispositivo client può utilizzare meccanismi WCF standard. In un esempio, il contratto o l’endpoint viene generato in formato dichiarativo. Il formato dichiarativo può essere XML. In una forma realizzativa, i contratti sono pubblicati sotto forma di modelli standard di linguaggio di definizione dei servizi web (WSDL, Web Service Definition Language). Oppure, gli endpoint o i contratti possono essere pubblicati utilizzando un trasferimento dello stato rappresentativo (REST), per esempio mediante implementazione di XML, Atom Syndication Format e/o Publishing Protocol (Atom) o JavaScript Object Notation (JSON). Gli endpoint possono comprendere un supporto Secure Sockets Layer (SSL) o Transport Layer Security (TSL).
La Fig. 17 è un diagramma di flusso che illustra un processo di esempio 1700 per generare, implementare e pubblicare un oggetto aziendale, generando automaticamente un endpoint dinamico per l’oggetto aziendale, e permettendo a un dispositivo client di consumare l’oggetto aziendale utilizzando l’endpoint dinamico. Preferibilmente, il processo 1700 è integrato in uno o più programmi software che sono memorizzati in una o più memorie ed eseguiti da uno o più processori. Per esempio, il processo 1700 può essere codice JavaScript (o qualsiasi altro tipo di software) in esecuzione su un dispositivo client 102. Sebbene il processo 1700 sia descritto con riferimento al diagramma di flusso illustrato in Fig. 17, si apprezzerà che possono essere utilizzati molti altri metodi per eseguire le operazioni associate al processo 1700. Per esempio, l’ordine di molti dei passaggi può essere modificato e alcuni dei passaggi descritti possono essere facoltativi. Inoltre, alcuni dei passaggi possono essere combinati in un unico passaggio.
Generalmente, viene creato un nuovo oggetto aziendale, il generatore di endpoint dinamici genera automaticamente le informazioni dell’endpoint per l’oggetto aziendale, e un dispositivo client può consumare l’oggetto aziendale senza necessità di generare manualmente un contratto o altre informazioni dell’endpoint, come un contratto, per l’oggetto aziendale.
Più specificamente, può essere utilizzato uno strumento di progettazione per creare un nuovo oggetto aziendale Prodotti, e l’oggetto aziendale viene quindi implementato e pubblicato su un server 192.168.1.38:7. Viene generato un endpoint dinamico “http://dlx.denallix.com:8000/Demo” per l’oggetto aziendale. Un dispositivo client remoto ProductsSvcClient può comunicare con l’endpoint in modo che l’endpoint fornisca informazioni di binding, contratti di metodi, dati e metadati. Il dispositivo client può utilizzare metodi come ProductsSvc_Create, ProductsSvc_Save, ProductsSvc_Delete, ProductsSvc_Load e ProductsSvc_GetList che possono essere associati all’oggetto aziendale Prodotti. Il dispositivo client ProductsSvcClient consuma l’oggetto aziendale Prodotti, e utilizzando uno o tutti i metodi crea record di prodotti ACME Widgets e ACME Gadgets.
Come illustrato in Fig. 18, l’utente può utilizzare uno strumento di progettazione 1800 per creare un nuovo oggetto aziendale. Lo strumento comprende template 1802 per creare progetti, processi o oggetti aziendali. Se l’utente vuole creare un nuovo oggetto aziendale vuoto, l’utente seleziona il template dell’oggetto aziendale 1804. Oppure, l’utente può accedere e riutilizzare altri oggetti aziendali utilizzati di recente come Clienti 1806 e Dipendenti 1808. L’utente poi preme il pulsante Crea per creare il nuovo oggetto aziendale denominato Prodotti 1810.
Ogni oggetto aziendale è tipicamente associato a proprietà e metodi. La Fig. 19 illustra un esempio in cui l’oggetto aziendale Prodotti 1810 ha cinque metodi predefiniti 1902 che l’utente può richiamare quando utilizza l’oggetto aziendale Prodotti 1810. I metodi fanno parte di un servizio SmartBox 1904 che è disponibile all’utente. Anche altri servizi possono essere disponibili all’utente, e l’utente può utilizzare e combinare servizi da molteplici sorgenti. Il nuovo oggetto aziendale Prodotti 1810 non ha ancora nessuna proprietà 1906 ad esso associata.
L’utente può aggiungere proprietà che definiscono l’oggetto aziendale. La Fig. 20 illustra che l’oggetto aziendale Prodotti 1810 è definito dalle proprietà ProductID 2002, Name 2004 e Category 2006. Anche altre proprietà possono essere disponibili all’utente, e l’utente può utilizzare e combinare proprietà da molteplici sorgenti. La ProductiD 2002 è elencata come la proprietà fondamentale poiché il valore ProductID è esclusivo per ogni Prodotto. Una volta definiti i metodi dell’oggetto aziendale Prodotti 1902 e le proprietà 1906, l’oggetto aziendale 1810 può essere implementato in un server come illustrato in Fig. 21.
Una volta implementato un oggetto aziendale, questo deve essere pubblicato. La pubblicazione di un oggetto aziendale rende l’oggetto aziendale individuabile dai client che possono volerlo utilizzare. La Fig. 22 è una schermata di esempio di pubblicazione dell’oggetto aziendale Prodotti 1810 sul server 192.168.1.38:7 2202. Una volta che l’oggetto aziendale è disponibile sul server, viene automaticamente generato un endpoint dinamico in modo che l’oggetto aziendale possa essere consumato da un client.
In una forma realizzativa, l’utente può avere la possibilità di configurare varie impostazioni correlate a un endpoint, per esempio se un endpoint sia abilitato per un oggetto aziendale, se l’oggetto aziendale sia escluso dall’avere endpoint, se sia utilizza un isolamento per l’endpoint e se siano utilizzati binding personalizzati per l’endpoint.
La Fig. 23 illustra un diagramma di flusso di esempio 2300 per la configurazione di informazioni dell’endpoint in risposta alla creazione e alla pubblicazione di un oggetto aziendale. Un oggetto aziendale SmartObject viene pubblicato nel passaggio 2302. Il generatore di endpoint dinamici quindi controlla se gli endpoint sono abilitati nei criteri di configurazione del passaggio 2304. Se gli endpoint non sono abilitati, non viene creato un endpoint come illustrato nel passaggio 2306. Se gli endpoint sono abilitati, il generatore di endpoint dinamici controlla se l’oggetto aziendale è stato escluso da un refresh del server o dalla creazione di endpoint, come illustrato nel passaggio 2308. Se l’oggetto aziendale è escluso, non viene creato un endpoint come illustrato nel passaggio 2310. Se l’oggetto aziendale non è escluso, il generatore di endpoint dinamici procede con la creazione di un endpoint per l’oggetto aziendale nel passaggio 2312.
Per generare un endpoint, il generatore di endpoint dinamici, in una forma realizzativa, carica la definizione dell’oggetto aziendale e mappa i tipi di dati ai tipi di dati supportati dall’endpoint nel passaggio 2314. Nel passaggio 2316, il generatore di endpoint dinamici genera contratti di dati per ogni tipo di dati dell’oggetto aziendale. Nel passaggio 2318, il generatore di endpoint dinamici genera contratti di operazioni e/o binding per ogni metodo dell’oggetto aziendale. Nel passaggio 2320, il generatore di endpoint dinamici genera un contratto di servizi per ogni categoria del sistema di categorie. Per esempio, il generatore di endpoint dinamici genera endpoint non soltanto per l’oggetto aziendale pubblicato nel passaggio 2302, ma per tutti gli oggetti aziendali appartenenti alla stessa categoria dell’oggetto aziendale o a tutte le categorie riconosciute dal generatore di endpoint dinamici.
Nel passaggio 2322, un utente può configurare se debba essere utilizzato un isolamento per l’endpoint. Se non deve essere utilizzato un isolamento, allora il dominio applicazione / memoria condivisa viene scaricato nel passaggio 2324. Un utente può configurare se debbano essere utilizzati binding personalizzati nel passaggio 2326. Se devono essere utilizzati binding personalizzati, viene creato un endpoint nella memoria condivisa con binding di sicurezza personalizzati nel passaggio 2328. Se non devono essere utilizzati binding personalizzati, viene creato un endpoint nella memoria condivisa con binding di sicurezza condivisi nel passaggio 2330.
Se deve essere utilizzato un isolamento nel passaggio 2322, viene creato un dominio applicazione / memoria isolata nel passaggio 2332. Nel passaggio 2338, un utente può configurare se debbano essere utilizzati binding personalizzati. Se devono essere utilizzati binding personalizzati, viene creato un endpoint nella memoria isolata con binding di sicurezza personalizzati nel passaggio 2336. Se non devono essere utilizzati binding personalizzati, viene creato un endpoint nella memoria isolata con binding di sicurezza condivisi nel passaggio 2338.
I criteri di configurazione possono essere predeterminati o può essere specificato il momento in cui viene creato un endpoint. La configurazione può essere eseguita a vari livelli diversi. Per esempio, un utente può essere in grado di configurare a livello dei servizi, a livello del protocollo WCF / REST o a un livello gestito. Utilizzando questi tre livelli di configurazione, un utente può controllare esattamente in maniera granulare dove e come viene generato un endpoint.
La configurazione dei servizi controlla la funzionalità predefinita dei servizi, compreso se i servizi siano abilitati o meno all’esecuzione, o se il generatore di endpoint ascolterà particolari eventi, per esempio la creazione di un nuovo oggetto aziendale. La configurazione WCF / REST permette a un utente di sovrascrivere la funzionalità dei servizi predefiniti e specificare un indirizzo di endpoint per ciascun tipo di endpoint, per es. WCF o REST.
La Tabella 1 fornisce un esempio di codice esemplificativo per una configurazione predefinita con endpoint abilitati.
TABELLA 1
(continua)
La configurazione gestita dell’endpoint permette a un utente non soltanto di specificare un endpoint statico per un oggetto aziendale specifico o una categoria di oggetti aziendali, ma anche di generare un endpoint isolato con il proprio indirizzo. Senza la configurazione gestita dell’endpoint, tutti gli endpoint generati sarebbero memorizzati in un singolo indirizzo, per es. http://dlx.denallix.com:8000/Demo, e la locazione di ogni oggetto aziendale sarebbe annessa a quell’indirizzo. Con la configurazione gestita dell’endpoint, un utente può specificare indirizzi per particolari endpoint, permettendo a tali endpoint di essere isolati.
Un endpoint può essere isolato in almeno tre modi: quando è memorizzato in uno spazio di memoria diverso da altri endpoint, quando è ubicato presso un Uniform Resource Identifier (URI) diverso dagli altri endpoint, e quando i binding di sicurezza sono diversi a livello del protocollo WCF / REST.
L’isolamento degli endpoint in un diverso spazio di memoria permette l’implementazione di un confine di sicurezza attorno a endpoint critici, e permette anche di isolare gli endpoint per essere singolarmente sottoposti a refresh, o esclusi dall’essere sottoposti a refresh quando altri endpoint vengono sottoposti a refresh. L’isolamento degli endpoint dal refresh può essere utile quando l’oggetto associato viene modificato di frequente. Oppure, un utente può desiderare di sottoporre a refresh solo un endpoint specifico, come può succedere quando vengono sviluppati o implementati oggetti associati. In una forma realizzativa, viene isolato solo un endpoint per la generazione dinamica.
Un secondo tipo di isolamento reso possibile dalla configurazione gestita dell’endpoint è l’isolamento URI, che permette l’accesso a un endpoint da isolare. Per esempio, un utente può essere in grado di ospitare tutti gli endpoint pubblici presso un URI comune, ma anche di ospitare particolari endpoint privati presso un diverso URI. Per accedere a questi endpoint privati, un dispositivo client deve conoscere l’URI specifico. Pertanto, l’individuazione e l’accesso agli endpoint possono essere isolati.
Un terzo tipo di isolamento reso possibile dalla configurazione gestita dell’endpoint è l’isolamento mediante binding di sicurezza, che permette di isolare l’accesso a un endpoint sulla base della configurazione del binding. Per esempio, un utente può essere in grado di ospitare tutti gli endpoint WCF e REST pubblici utilizzando un binding di sicurezza comune per i protocolli WCF e REST, ma anche di ospitare particolari endpoint privati utilizzando una configurazione del binding di sicurezza esclusiva per i protocolli WCF o REST.
In una forma realizzativa, i vari livelli di impostazioni di configurazione rendono possibile l’ereditarietà dei parametri di configurazione. In una forma realizzativa, la configurazione dei servizi sovrascrive le impostazioni predefinite, la configurazione WCF / REST sovrascrive le impostazioni della configurazione dei servizi (cosicché un utente possa configurare tutti gli endpoint che corrispondono agli endpoint di tipo WCF / REST) e la configurazione gestita dell’endpoint sovrascrive le impostazioni di configurazione WCF / REST (cosicché un utente possa configurare singoli oggetti aziendali o categorie di oggetti aziendali). Ogni successivo livello di configurazione – dalla configurazione di servizi alla configurazione WCF / REST alla configurazione gestita dell’endpoint -applica una logica più forte che aumenta le condizioni sugli endpoint nel momento in vengono generati.
La Tabella 2 fornisce un esempio di pseudo-codice esemplificativo per le opzioni di configurazione delle impostazioni in una forma realizzativa.
TABELLA 2
Servizi
• enableEndpoints (Booleano) - determina se verrà avviato il servizio K2 SmartObjectServices
o Vero - avvia K2 SmartObject Services e carica gli endpoint configurati
o Falso (predefinito/omesso) - non avvia K2 SmartObjectServices o non carica alcun endpoint
• enableEvents (Booleano) - determina se le modifiche a SmartObjects saranno riflesse dinamicamente senza riavviare K2 Server
o Vero (predefinito/omesso) - quando vengono creati/modificati/cancellati SmartObjects, il servizio ricaricherà dinamicamente l’AppDomain contenente gli SmartObjects interessati
o Falso - quando vengono creati/aggiornati/cancellati SmartObjects, il servizio non rispecchierà le modifiche senza riavviare K2 Server
• enableCrossDomainPolicy (Booleano) - determina se gli endpoint del servizio avranno un supporto cross-domain
o Vero - abilita il supporto cross-domain permettendo ad applicazioni basate sul browser, come Silverlight, di effettuare chiamate all’endpoint del servizio da un dominio diverso
• File - i file che controllano il livello di supporto cross-domain sono crossdomain.xml e clientaccesspolicy.xml. Questi file possono essere trovati e editati nella directory [Installation Directory]\Host Server\Bin\SmOServices.
• NOTA: il valore del server deve essere un nome DNS o un nome macchina pienamente qualificato perché il supporto cross-domain funzioni adeguatamente.
o Falso (predefinito/omesso) - disabilita il supporto cross-domain non permettendo alle applicazioni basate sul browser, come Silverlight, di effettuare chiamate all’endpoint del servizio da un dominio diverso
• enableMetadata (Booleano) - determina se verrà generato un documento di metadati del servizio (aka, WSDL) tramite ?wsdl per l’endpoint o Vero (predefinito/omesso) - sarà creato un documento di metadati del servizio per l’endpoint
o Falso - non sarà creato un documento di metadati del servizio per l’endpoint
• schema (Stringa, richiesto) - lo schema predefinito (http o https se SSL è abilitato) per gli endpoint.
o Predefinito: http
• server (Stringa, richiesto) - il DNS o nome di dominio pienamente qualificato del server che ospita gli endpoint
o Predefinito: {nome macchina pienamente qualificato}
• porta (Stringa) - la porta predefinita per gli endpoint
o Predefinito: 8888
o Omesso: 80
• serviceRoot (Stringa) - la radice del servizio predefinita per gli endpoint
o Predefinito: SmartObjectServices
• specialCharacterReplacement (Stringa) - permette agli amministratori di controllare quale carattere è utilizzato al posto di caratteri generati non permessi come gli spazi
o Predefinito/Omesso: _
• defaultSecurityLabel (Stringa) - imposta l’etichetta di sicurezza predefinita da pre-apporre al nome utente per i metodi di autenticazione di base o Predefinito: K2
o Omesso: non verrà pre-apposta alcuna etichetta di sicurezza, il nome utente deve anche contenere l’etichetta WCF
La sezione <wcf> contiene la configurazione del binding predefinita per gli endpoint e i componenti URI dei Servizi WCF specifici opzionali.
• binding (Stringa, richiesto) - imposta il tipo di binding predefinito per l’endpoint WCF
o Supporta basicHttpBinding, wsHttpBinding
o Predefinito: wsHttpBinding
• bindingConfiguration (Stringa, richiesto) - imposta la configurazione nella sezione <system.serviceModel> che contiene i dettagli del binding per l’endpoint
o Predefinito: wsHttpBinding+Windows
• bindingConfiguration (Stringa, richiesto) - imposta la configurazione nella sezione <system.serviceModel> che contiene i dettagli del binding per l’endpoint
• schema (Stringa) - se presente, sovrascrive lo schema predefinito e richiede il server
• server (Stringa) - se presente, sovrascrive il server predefinito e richiede lo schema
• porta (Stringa) - se presente, sovrascrive la porta predefinita
• serviceRoot (Stringa) - se presente, sovrascrive la radice del servizio predefinita
• defaultSecurityLabel (Stringa) - se presente, sovrascrive l’etichetta di sicurezza predefinita
• individualSmartObjects (Booleano) - se presente, genererà un endpoint per ogni singolo SmartObject in aggiunta all’endpoint a livello della categoria
o Predefinito: falso
REST
La sezione <rest> contiene la configurazione di binding predefinita per gli endpoint REST e i componenti URI dei Servizi REST specifici opzionali.
• binding (Stringa, richiesto) - imposta il tipo di binding predefinito per l’endpoint REST
o Supporto per webHttpBinding
o Predefinito: webHttpBinding
• bindingConfiguration (Stringa, richiesto) - imposta la configurazione nella sezione <system.serviceModel> che contiene i dettagli del binding per l’endpoint
o Predefinito: webHttpBinding+Windows
• schema (Stringa) - se presente, sovrascrive lo schema predefinito e richiede il server
• server (Stringa) - se presente, sovrascrive il server predefinito e richiede lo schema
• porta (Stringa) - se presente, sovrascrive la porta predefinita
• serviceRoot (Stringa) - se presente, sovrascrive la radice del servizio predefinita
• defaultSecurityLabel (Stringa) - se presente, sovrascrive l’etichetta di sicurezza predefinita
Endpoint gestiti
La categoria è l’oggetto di livello alto predefinito che è vincolato all’endpoint tramite l’URI. Per esempio, se una categoria e uno SmartObject sono presenti allo stesso livello, l’endpoint sarà vincolato alla categoria. Oltre al binding predefinito dei metodi degli SmartObjects per un endpoint della categoria, è possibile configurare gli SmartObjects per avere propri endpoint (navigazione tramite URI diretta allo SmartObject). Nel caso in cui una categoria e uno SmartObject finiscano per avere lo stesso endpoint, la categoria prevarrà e sarà vincolata all’endpoint e verrà registrato un errore per la collisione.
La gestione degli endpoint permette all’amministratore di controllare quali categorie e SmartObjects sono disponibili attraverso i servizi WCF e REST. Ci sono due principali sezioni: Esclusi e Statici.
• Esclusi significa che il percorso della categoria e gli SmartObjects di quella categoria sono esclusi. Le singole sottocategorie non vengono escluse automaticamente e richiederanno un’immissione separata.
• Statici significa che la categoria specifica e, a seconda dello scenario, SmartObject specifici sono inclusi.
Esclusi
Configura gli endpoint esclusi per impedire che sia generato un endpoint per una categoria o sottocategoria e i metodi degli SmartObject di quella categoria/sottocategoria.
• tutto (Booleano, richiesto) - determina se saranno escluse tutte le categorie
o Vero (predefinito) - esclude tutte le categorie dalla generazione di endpoint.
o Falso - genera endpoint per tutte le categorie non esplicitamente escluse
• la sezione <endpoints> contiene un <endpoint> per ogni percorso di categoria da escludere esplicitamente
o categoryPath (Stringa, richiesto) - il percorso alla categoria/sottocategoria
Esempio 1: esclude la categoria Task Allocation dalla generazione di endpoint. Tutte le sottocategorie rimarrebbero comunque incluse.
<endpoint categoryPath=“Task Allocation”/>
Esempio 2: esclude la sottocategoria Workflow Reports/Workflow General dalla generazione di endpoint. La categoria padre, Workflow Reports, e le eventuali sottocategorie rimarrebbero comunque incluse. <endpoint categoryPath=“Workflow Reports/Workflow General”/>
o excludeSubCategories (Booleano, opzionale) - il percorso della categoria/sottocategoria
Vero - esclude la categoria padre e tutte le sottocategorie dalla generazione di endpoint.
Falso (predefinito) - genera endpoint per tutte le sottocategorie non esplicitamente escluse
Esempio 1: esclude la categoria Task Allocation e tutte le sue sottocategorie dalla generazione di endpoint.
<endpoint categoryPath=“Task Allocation” excludeSubCategories=“true”/>
Statici
Configura endpoint statici per permettere una mappatura biunivoca di uno SmartObject a un endpoint, l’aliasing dell’URI dello SmartObject, la creazione di un AppDomain personalizzato, la modifica del tipo di binding predefinito e la selezione di una versione di definizione dello SmartObject specifica.
• categoryPath (Stringa) (richiesto) - il percorso alla categoria/sottocategoria
o Esempio 1: include tutti gli SmartObjects in una categoria.
<endpoint categoryPath=“MyCategory/MyProject” /> o Quando specificato senza un nome di SmartObject specifico nell’attributo smartobjectName o individualSmartObjects=true, verranno generati tutti gli SmartObjects di questo percorso di categoria. Inoltre, se un percorso di categoria specificato non esiste, questo verrà comunque tenuto sotto controllo in modo da generare l’endpoint nel caso in cui sia successivamente implementato uno SmartObject in questo percorso di categoria.
• smartobjectName (Stringa, opzoinale) - il nome dello SmartObject specifico
o specificato - quando specificato, lo SmartObject otterrà la generazione di un endpoint
o mancante - quando non specificato, verranno generati tutti gli SmartObjects presenti nel percorso di categoria specificato • alias (Stringa, opzionale) - il nuovo percorso da utilizzare per navigare all’endpoint per questo SmartObject o Categoria. NOTA: la ricerca del percorso utilizzerà il nome visualizzato mentre il binding che è generato continuerà a utilizzare il nome di sistema.
o Se c’è una collisione con una Categoria o uno SmartObject esistente, allora prevarrà quest’ultimo. Per esempio, se si configurano due endpoint statici con esattamente lo stesso alias, il secondo della lista sovrascriverà il primo e ci sarà un solo endpoint.
o Esempio: alias=“MySmartObjectAlias” genererà un binding dell’endpoint per lo SmartObject all’indirizzo http://api.denallix.com:8888/SmartObjectServices/MySmartO bject
• isolationLevel (Stringa, opzionale) - utilizzato per specificare l’AppDomain che l’endpoint dovrebbe utilizzare
o condiviso (predefinito/omesso) - per impostazione predefinita tutti gli endpoint utilizzeranno un singolo AppDomain. La mancata impostazione di isolationLevel o specifica di isolationLevel=“shared” ha lo stesso effetto dell’utilizzo dell’AppDomain del servizio.
o singolo - l’impostazione di isolationLevel=“single” assicurerà che l’endpoint per questo SmartObject abbia il proprio AppDomain per permettere l’isolamento da tutti gli altri endpoint. Questo è utile quando lo SmartObject viene modificato di frequente, poiché il ricaricamento dell’endpoint non interesserà gli altri endpoint
• smartobjectVersion (Stringa, opzoinale) - utilizzato per specificare una versione specifica della definizione dello SmartObject da vincolare all’endpoint. Per impostazione predefinita sarà vincolata la versione di definizione dello SmartObject più recente.
o Esempio: 5
• La sezione <wcf> o <rest>, se presente, sovrascrive la configurazione WCF e/o REST per il servizio per questo endpoint statico.
o binding (Stringa) - se presente, sovrascrive il tipo di binding predefinito configurato per il servizio WCF o REST
Supporto per basicHttpBinding, wsHttpBinding, webHttpBinding
o bindingConfiguration (Stringa) - se presente, sovrascrive la configurazione del binding predefinita per il servizio WCF/REST
o schema (Stringa) - se presente, sovrascrive lo schema predefinito e richiede il server
o server (Stringa) - se presente, sovrascrive il server predefinito e richiede lo schema
o porta (Stringa) - se presente, sovrascrive la porta predefinita o serviceRoot (Stringa) - se presente, sovrascrive la radice del servizio predefinita
o defaultSecurityLabel (Stringa) - se presente, sovrascrive l’etichetta di sicurezza predefinita
o individualSmartObjects (Booleano) - se presente, genererà un endpoint per ogni singolo SmartObject in aggiunta all’endpoint a livello di categoria
Predefinito: falso
La Tabella 3 illustra un esempio di utilizzo delle opzioni di configurazione degli endpoint, dove gli endpoint WCF ereditano una configurazione del livello di servizio predefinita, gli endpoint REST sovrascrivono la configurazione del livello di servizio predefinita, e anche gli endpoint gestiti sovrascrivono la configurazione del livello di servizio predefinita.
TABELLA 3
In una forma realizzativa, il generatore di endpoint dinamici genera automaticamente un endpoint per un oggetto aziendale non appena viene creato l’oggetto aziendale. Il generatore di endpoint dinamici carica una definizione dell’oggetto aziendale e itera attraverso la definizione. La definizione dell’oggetto aziendale può comprendere proprietà e metodi. La definizione dell’oggetto è mappata ad ogni tipo di endpoint supportato, per esempio WCF o REST, le proprietà sono mappate a contratti di dati e i metodi sono mappati a contratti di operazioni. I metodi possono avere firme che descrivono i metodi. Per esempio, le firme dei metodi possono definire un insieme minimo di informazioni necessarie perché un metodo funzioni adeguatamente, come i tipi di dati di input e output di un metodo.
Il generatore di endpoint dinamici assicura che le firme per i metodi dell’oggetto aziendale contengano input e output supportati da ogni tipo di endpoint. In caso contrario, il generatore di endpoint dinamici crea tali firme per ogni metodo di oggetto aziendale.
Le Figg. da 24 a 27 illustrano un esempio di consumo di un endpoint dinamico che è stato generato per un oggetto aziendale. In un esempio, è necessario eseguire un servizio prima che qualsiasi client possa utilizzare l’endpoint. Il servizio è specifico dell’ambiente in cui il client risiede. Un client può quindi richiamare quel servizio e utilizzare i metodi che fanno parte del servizio.
La Fig. 24 illustra che un servizio ProductsSvc 2402 presso l’endpoint “http://dlx.denallix.com:8000/Demo” 2404 permetterà ai client di utilizzare i metodi ProductsSvc Create 2406, ProductsSvc Save 2408, ProductsSvc Delete 2410, ProductsSvc Load 2412 e ProductsSvc_GetList 2414 che sono associati all’oggetto aziendale Prodotti 1810.
La Fig. 25 illustra che il generatore di endpoint dinamici crea una pagina 2500 presso endpoints.xml che elenca tutti gli endpoint WCF e REST che sono stati generati sulla base della configurazione corrente. La pagina 2500 può essere aggiornata ogni qualvolta è implementato un oggetto aziendale nuovo o aggiornato che induce un refresh del server.
La Fig. 26 illustra un esempio di codice 2602 che può essere utilizzato per testare se un servizio funziona. Un client denominato ProductsSvcClient 2604 può utilizzare i servizi disponibili presso l’endpoint “http://dIx.denallix.com:8000/Demo” 2404. La Fig. 27 illustra l’endpoint 2404 in WSDL che viene generato automaticamente in modo che i client possano utilizzare l’oggetto Prodotti 1810 e i metodi 1902 associati all’oggetto Prodotti 1810. La Fig. 27 elenca un esempio di un indirizzo 2702, un binding 2704 e un contratto 2706 per l’endpoint 2404 per l’oggetto Prodotti 1810. Un client può consumare l’oggetto aziendale Prodotti 1810 senza necessità di generare manualmente le informazioni dell’endpoint.
La Fig. 28 è una schermata di esempio di creazione di una nuova applicazione per dispositivo client 2800. Il client può utilizzare qualsiasi interfaccia disponibile nel framework .NET 2802, per esempio un’interfaccia utente Windows Forms 2804. Sono disponibili anche altre interfacce 2806. Per esempio, il client può utilizzare qualsiasi framework che consuma endpoint, come Java, JavaScript o HTML 5.
In una forma realizzativa, il client 2800 si abbona a un servizio associato all’oggetto aziendale Prodotti 1810 prima che possa consumare l’oggetto aziendale Prodotti 1810. La Fig. 29 è una schermata di esempio del client 2800 con l’aggiunta di un riferimento al servizio 2902.
La Fig. 30 è una schermata di esempio del client 2800 che comunica con un oggetto aziendale 1810 utilizzando un endpoint dinamico 2404. Nello specifico, il client 2800 può accedere alle operazioni 2406, 2408, 2410, 2412 e 2414 associate all’oggetto Prodotti 1810. In una forma realizzativa, un client 2800 può tentare di individuare un oggetto aziendale utilizzando una funzione Individua 3002. L’oggetto aziendale non dispone ancora di un endpoint o un contratto che possa essere utilizzato dal client. In una forma realizzativa, dopo che il cliente tenta di individuare in modalità remota un oggetto aziendale, il server costruisce e pubblica contratti per l’oggetto aziendale richiesto dal client.
In Fig. 30, una volta che il client 2800 aggiunge il servizio ProductsSvc 2402 presso l’endpoint “http://dlx.denallix.com:8000/Demo” 2404, il client 2800 può utilizzare tutte le operazioni ProductsSvc_Create 2406, ProductsSvc_Save 2408, ProductsSvc Delete 2410, ProductsSvc_Load 2412 e ProductsSvc_GetList 2414 che sono associate all’oggetto aziendale Prodotti 1810.
La Fig. 31 è una schermata di esempio di metadati di oggetto aziendale forniti a un dispositivo client. Nell’esempio, il client ProductsSvcClient 2604 è in grado di accedere ai metadati dell’oggetto aziendale Prodotti 3102 – nello specifico, il campo Name è un tipo di stringa nel formato Products.Name.
La Fig. 32 è una schermata di esempio di dati e metodi dell’oggetto aziendale forniti a un dispositivo client. Nell’esempio, il client ProductsSvcClient 2604 è in grado di utilizzare i dati dell’oggetto aziendale Prodotti 3202 e i metodi dell’oggetto aziendale Prodotti 1902.
Le Figg. da 33 a 35 illustrano esempi di un dispositivo client che utilizza e consuma un oggetto aziendale esposto in un endpoint WCF. La Fig. 33 è una schermata di esempio del dispositivo client che crea un nuovo record Prodotto ACME Widgets 3302 utilizzando l’oggetto aziendale Prodotti 1810. Prima che sia creato il record, non ci sono record Prodotto nell’area dei record 3304. Una volta premuto il pulsante Crea Prodotto 3306, viene creato un nuovo prodotto come illustrato in Fig. 34.
La Fig. 34 è una schermata di esempio di un nuovo prodotto denominato ACME Widgets 3302 con un Productld di 1. L’area dei record 3304 ora elenca ACME Widgets 3302 come record. L’oggetto aziendale Prodotti 1810 può essere riutilizzato per creare molteplici prodotti. Per esempio, la Fig. 35 è una schermata di esempio di un altro nuovo prodotto denominato ACME Gadgets 3502 con un ProductId di 2. L’area dei record 3304 mostra sia ACME Widgets 3302 sia ACME Gadgets 3502. Entrambi i prodotti ACME Widgets 3302 e ACME Gadgets 3502 sono stati creati utilizzando una forma realizzativa di un endpoint dinamico.
Le Figg. da 36 a 39 illustrano esempi di un dispositivo client che utilizza e consuma un oggetto aziendale esposto in un endpoint REST per mostrare in che modo potrebbero essere creati ACME Gadgets utilizzando un endpoint REST. La Fig. 36 è una schermata di esempio di un dispositivo client che utilizza il metodo GetList 2414 in XML. Il metodo GetList 2414 è un metodo per l’oggetto aziendale Prodotti 1810. L’uso del metodo GetList 2414 mostra che vi è inizialmente un solo oggetto aziendale Prodotti ACME Widgets 3302.
La Fig. 37 è una schermata di esempio di creazione di un oggetto aziendale Prodotti 1810 utilizzando il metodo Crea 2406. La Fig. 37 mostra la creazione di un nuovo oggetto aziendale Prodotti denominato ACME Gadgets 3502.
La Fig. 38 è una schermata di esempio di un nuovo utilizzo del metodo GetList 2414 dopo la creazione di ACME Gadgets 3502. La Fig. 38 illustra che il metodo GetList 2414 ora fornisce come risultato due oggetti aziendali Prodotti: ACME Widgets 3302 e ACME Gadgets 3502.
La Fig. 39 è una schermata di esempio di utilizzo del metodo GetList 2414 in un feed Atom. La Fig. 39 illustra che il metodo GetList 2414 fornisce come risultato due file di oggetti aziendali Prodotti per i due oggetti ACME Widgets e ACME Gadgets in un feed Atom.
In una forma realizzativa, qualsiasi risorsa business può essere resa disponibile a un client attraverso un endpoint dinamico. Per esempio, oggetti aziendali, processi o worklist possono essere esposti attraverso un endpoint dinamico.
Utilizzando i sistemi descritti, gli sviluppatori dispongono di un accesso dinamico istantaneo, libero da piattaforma, a qualsiasi oggetto aziendale. In una forma realizzativa, sistemi backend standardizzati come SAP, Siebel, Oracle DB, Oracle EBS e SQL vengono esposti attraverso l’endpoint dinamico. In una forma realizzativa, sistemi backend proprietari possono essere esposti, per esempio, utilizzando adattatori. Gli adattatori rendono più facile l’esposizione di oggetti che sono memorizzati su sistemi proprietari.
In sintesi, le persone con normali competenze nel campo apprezzeranno facilmente che sono stati descritti metodi e un apparato per generare dinamicamente, individuare, accedere e consumare oggetti aziendali. La descrizione che precede è presentata a scopo di illustrazione e descrizione. Non è intesa ad essere esaustiva o a limitare l’invenzione alle forme realizzative di esempio descritte. Sono possibili numerose modifiche e variazioni alla luce dei principi inventivi sopra esposti. L’ambito dell’invenzione non è inteso a essere limitato dalla presente descrizione dettagliata degli esempi, ma piuttosto dalle rivendicazioni qui annesse.

Claims (24)

  1. RIVENDICAZIONI 1. Metodo di generazione di un endpoint dinamico che permette a un dispositivo client di consumare un oggetto aziendale, l’endpoint comprendendo un indirizzo, un legame (binding) e un contratto, il metodo comprendendo: il caricamento di una definizione dell’oggetto aziendale, la definizione avendo proprietà e metodi; l’iterazione attraverso la definizione; e la mappatura della definizione a protocolli supportati dall’endpoint, la mappatura comprendendo: (i) la mappatura delle proprietà dell’oggetto aziendale a contratti di dati; (ii) la mappatura dei metodi dell’oggetto aziendale a contratti di operazioni; e (iii) l’assicurazione che le firme dei metodi dell’oggetto aziendale abbiano input e output supportati dall’endpoint; dove l’endpoint è generato in risposta ad almeno uno tra (a) il dispositivo client che richiede l’oggetto aziendale, (b) l’oggetto aziendale che viene creato e (c) l’oggetto aziendale che viene aggiornato.
  2. 2. Metodo della rivendicazione 1, comprendente inoltre la generazione di endpoint .NET per l’uso in un framework WCF e la generazione di endpoint Atom, XML e JSON per l’uso in un framework REST.
  3. 3. Metodo della rivendicazione 1, in cui l’oggetto aziendale appartiene a una categoria, e l’endpoint è generato per la categoria.
  4. 4. Metodo della rivendicazione 1, comprendente inoltre la generazione dell’endpoint sulla base di una configurazione.
  5. 5. Metodo della rivendicazione 4, in cui la configurazione comprende la configurazione di servizi, la configurazione WCF, la configurazione REST e la configurazione gestita.
  6. 6. Metodo della rivendicazione 5, in cui la configurazione gestita comprende configurare se sia generato un endpoint statico per l’oggetto aziendale e se l’endpoint sia isolato.
  7. 7. Metodo della rivendicazione 6, in cui l’isolamento comprende almeno uno tra (i) l’isolamento di memoria, (ii) l’isolamento di indirizzo e (iii) l’isolamento di binding di sicurezza.
  8. 8. Metodo della rivendicazione 6, in cui la configurazione dell’isolamento permette di configurare almeno una tra le possibilità (i) che un server ricostruisca tutti gli endpoint sul server o (ii) che il server ricostruisca meno di tutti gli endpoint sul server.
  9. 9. Istruzioni di memorizzazione su un supporto leggibile tramite elaboratore per la generazione di un endpoint dinamico che permette a un dispositivo client di consumare un oggetto aziendale, l’endpoint comprendendo un indirizzo, un legame (binding) e un contratto, le istruzioni inducendo il dispositivo di elaborazione a: caricare una definizione dell’oggetto aziendale, la definizione avendo proprietà e metodi; iterare attraverso la definizione; e mappare la definizione a protocolli supportati dall’endpoint, la mappatura comprendendo: (i) la mappatura delle proprietà dell’oggetto aziendale a contratti di dati, (ii) la mappatura dei metodi dell’oggetto aziendale a contratti di operazioni, e (iii) l’assicurazione che le firme dei metodi dell’oggetto aziendale abbiano input e output supportati dall’endpoint; in cui l’endpoint è generato in risposta ad almeno uno tra (a) il dispositivo client che richiede l’oggetto aziendale, (b) l’oggetto aziendale che viene creato e (c) l’oggetto aziendale che viene aggiornato.
  10. 10. Supporto leggibile tramite elaboratore della rivendicazione 9, le istruzioni inducendo inoltre il dispositivo di elaborazione a generare endpoint .NET per l’uso in un framework WCF e a generare endpoint Atom, XML e JSON per l’uso in un framework REST.
  11. 11. Supporto leggibile tramite elaboratore della rivendicazione 9, in cui l’oggetto aziendale appartiene a una categoria, e l’endpoint è generato per la categoria.
  12. 12. Supporto leggibile tramite elaboratore della rivendicazione 9, le istruzioni inducendo inoltre il dispositivo di elaborazione a generare l’endpoint sulla base di una configurazione.
  13. 13. Supporto leggibile tramite elaboratore della rivendicazione 12, in cui la configurazione comprende la configurazione di servizi, la configurazione WCF, la configurazione REST e la configurazione gestita.
  14. 14. Supporto leggibile tramite elaboratore della rivendicazione 13, in cui la configurazione gestita comprende configurare se sia generato un endpoint statico per l’oggetto aziendale e se l’endpoint sia isolato.
  15. 15. Supporto leggibile tramite elaboratore della rivendicazione 14, in cui l’isolamento comprende almeno uno tra (i) l’isolamento della memoria, (ii) l’isolamento dell’indirizzo e (iii) l’isolamento del binding di sicurezza.
  16. 16. Supporto leggibile tramite elaboratore della rivendicazione 14, in cui la configurazione dell’isolamento permette di configurare almeno una tra le possibilità (i) che un server ricostruisca tutti gli endpoint sul server o (ii) che il server ricostruisca meno di tutti gli endpoint sul server.
  17. 17. Sistema per la generazione di un endpoint dinamico che permette a un dispositivo client di consumare un oggetto aziendale, l’endpoint comprendendo un indirizzo, un legame (binding) e un contratto comprendente un processore strutturato per indurre il sistema a: caricare una definizione dell’oggetto aziendale, la definizione avendo proprietà e metodi; iterare attraverso la definizione, e mappare la definizione a protocolli supportati dall’endpoint, la mappatura comprendendo: (i) la mappatura delle proprietà dell’oggetto aziendale a contratti di dati, (ii) la mappatura dei metodi dell’oggetto aziendale a contratti di operazioni, e (iii) l’assicurazione che le firme dei metodi dell’oggetto aziendale abbiano input e output supportati dall’endpoint; in cui l’endpoint è generato in risposta ad almeno uno tra (a) il dispositivo client che richiede l’oggetto aziendale, (b) l’oggetto aziendale che viene creato e (c) l’oggetto aziendale che viene aggiornato.
  18. 18. Sistema della rivendicazione 17, il processore essendo strutturato per indurre inoltre il sistema a generare endpoint .NET per l’uso in un framework WCF e generare endpoint Atom, XML e JSON per l’uso in un framework REST.
  19. 19. Sistema della rivendicazione 17, in cui l’oggetto aziendale appartiene a una categoria, e l’endpoint è generato per la categoria.
  20. 20. Sistema della rivendicazione 17, il processore essendo strutturato per indurre inoltre il sistema a generare l’endpoint sulla base di una configurazione.
  21. 21. Sistema della rivendicazione 20, in cui la configurazione comprende la configurazione di servizi, la configurazione WCF, la configurazione REST e la configurazione gestita.
  22. 22. Sistema della rivendicazione 21, in cui la configurazione gestita comprende configurare se sia generato un endpoint statico per l’oggetto aziendale e se l’endpoint sia isolato.
  23. 23. Sistema della rivendicazione 22, in cui l’isolamento comprende almeno uno tra (i) l’isolamento di memoria, (ii) l’isolamento di indirizzo e (iii) l’isolamento di binding di sicurezza.
  24. 24. Sistema della rivendicazione 22, in cui la configurazione dell’isolamento permette di configurare almeno una tra le possibilità (i) che un server ricostruisca tutti gli endpoint sul server o (ii) che il server ricostruisca meno di tutti gli endpoint sul server. Milano, 8 novembre 2013
IT000390U 2010-09-21 2013-11-08 Metodi e apparato per generatori di endpoint dinamici, individuazione e mediazione (brokerage) di oggetti remoti dinamici ITMI20130390U1 (it)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US38487910P 2010-09-21 2010-09-21

Publications (1)

Publication Number Publication Date
ITMI20130390U1 true ITMI20130390U1 (it) 2014-02-07

Family

ID=44736082

Family Applications (1)

Application Number Title Priority Date Filing Date
IT000390U ITMI20130390U1 (it) 2010-09-21 2013-11-08 Metodi e apparato per generatori di endpoint dinamici, individuazione e mediazione (brokerage) di oggetti remoti dinamici

Country Status (5)

Country Link
US (2) US8832175B2 (it)
AU (2) AU2011305494B2 (it)
GB (1) GB2498301A (it)
IT (1) ITMI20130390U1 (it)
WO (1) WO2012040341A2 (it)

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120072509A1 (en) * 2010-09-03 2012-03-22 Booth Lloyd George Method and system for integrating applications within a work process
US8930575B1 (en) * 2011-03-30 2015-01-06 Amazon Technologies, Inc. Service for automatically converting content submissions to submission formats used by content marketplaces
US8856736B2 (en) * 2011-05-10 2014-10-07 Microsoft Corporation Web service proxy interface augmentation
US8862975B2 (en) * 2011-09-19 2014-10-14 Microsoft Corporation Web-based workflow service visualization and navigation
CN104063234B (zh) * 2013-03-19 2017-06-27 华为技术有限公司 一种兼容方法及装置
ES2527566B1 (es) * 2013-07-26 2015-09-29 Sourcecode Technology Holdings, Inc. Método, medio y sistema de generación de un punto final dinámico
US9223773B2 (en) * 2013-08-08 2015-12-29 Palatir Technologies Inc. Template system for custom document generation
US9667691B2 (en) * 2014-11-20 2017-05-30 Futurewei Technologies, Inc. Method for retrieving service capability of a group of contacts
US9825814B2 (en) * 2015-05-28 2017-11-21 Cisco Technology, Inc. Dynamic attribute based application policy
US9635007B2 (en) 2015-09-24 2017-04-25 Heat Software Usa Inc. Dynamic web services server
US11171924B2 (en) 2015-10-14 2021-11-09 Adp, Inc. Customized web services gateway
US10348816B2 (en) 2015-10-14 2019-07-09 Adp, Llc Dynamic proxy server
US10623528B2 (en) 2015-10-14 2020-04-14 Adp, Llc Enterprise application ecosystem operating system
US9860346B2 (en) 2015-10-14 2018-01-02 Adp, Llc Dynamic application programming interface builder
US9800585B2 (en) * 2015-10-21 2017-10-24 Red Hat, Inc. Restricting access by services deployed on an application server
US10348592B2 (en) * 2017-02-08 2019-07-09 Dell Products L.P. Systems and methods for dynamic availability of executable endpoints
EP3367316A1 (en) 2017-02-21 2018-08-29 SourceCode Technology Holdings, Inc. Collaborative design systems, apparatuses, and methods
US10540190B2 (en) * 2017-03-21 2020-01-21 International Business Machines Corporation Generic connector module capable of integrating multiple applications into an integration platform
US10990368B2 (en) * 2017-12-26 2021-04-27 Oracle International Corporation On-premises and cloud-based software provisioning
US10521246B1 (en) 2018-06-13 2019-12-31 International Business Machines Corporation Application programming interface endpoint analysis and modification
EP4154129A1 (en) * 2020-05-22 2023-03-29 Invixo Consulting Group A/S Database management methods and associated apparatus
US11853739B2 (en) * 2020-10-22 2023-12-26 Ivanti, Inc. Automated endpoint product management
US11379276B2 (en) * 2020-11-02 2022-07-05 Sourcecode Technology Holdings, Inc. Event translation for business objects
US20220138691A1 (en) * 2020-11-02 2022-05-05 Sourcecode Technology Holdings, Inc. Event registration for business objects

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6763353B2 (en) * 1998-12-07 2004-07-13 Vitria Technology, Inc. Real time business process analysis method and apparatus
US6708164B1 (en) * 2000-03-17 2004-03-16 Microsoft Corporation Transforming query results into hierarchical information
US7099727B2 (en) * 2002-10-25 2006-08-29 Sap Aktiengesellschaft Knowledge repository system for computing devices
US20040224674A1 (en) * 2003-04-07 2004-11-11 O'farrell Robert System and method for context sensitive mobile data and software update
US7885847B2 (en) * 2003-05-07 2011-02-08 Sap Ag End user oriented workflow approach including structured processing of ad hoc workflows with a collaborative process engine
US7415484B1 (en) * 2003-05-09 2008-08-19 Vignette Corporation Method and system for modeling of system content for businesses
US7634482B2 (en) * 2003-07-11 2009-12-15 Global Ids Inc. System and method for data integration using multi-dimensional, associative unique identifiers
US20060184452A1 (en) * 2003-10-14 2006-08-17 Maccord Mason Pllc, Electronic document management system
US7398512B2 (en) * 2003-12-02 2008-07-08 Hewlett-Packard Development Company, L.P. Method, system, and software for mapping and displaying process objects at different levels of abstraction
US20060200772A1 (en) * 2003-12-08 2006-09-07 Sathiyamoorthy Dhanapal Procedural computation engine for providing complex calculated data results to an object-oriented server system accessible to service clients and agents over a data packet network
US20050216282A1 (en) * 2004-03-25 2005-09-29 International Business Machines Corporation System and method for business object discovery
US20060130038A1 (en) * 2004-12-15 2006-06-15 Claussen Christopher S Apparatus, system, and method for facilitating dynamic modification of existing software objects defined in a strongly-typed programming language
US7950023B2 (en) 2005-02-04 2011-05-24 Microsoft Corporation Utilizing abstract descriptions to generate, exchange, and configure service and client runtimes
US20060235899A1 (en) * 2005-03-25 2006-10-19 Frontline Systems, Inc. Method of migrating legacy database systems
US7805752B2 (en) * 2005-11-09 2010-09-28 Symantec Corporation Dynamic endpoint compliance policy configuration
US7752207B2 (en) * 2007-05-01 2010-07-06 Oracle International Corporation Crawlable applications
US8694880B2 (en) * 2007-09-25 2014-04-08 Oracle International Corporation Population update framework, systems and methods
US8239371B2 (en) * 2008-08-21 2012-08-07 Sap Ag Fast search views over business objects
US8572157B2 (en) * 2011-01-31 2013-10-29 Microsoft Corporation Configuration based approach to unify web services
US8650150B2 (en) * 2011-03-14 2014-02-11 Sap Ag System and method of relating data and generating reports

Also Published As

Publication number Publication date
US20140359088A1 (en) 2014-12-04
WO2012040341A3 (en) 2012-05-10
GB201306698D0 (en) 2013-05-29
GB2498301A (en) 2013-07-10
AU2016202239A1 (en) 2016-05-05
WO2012040341A2 (en) 2012-03-29
US20120143938A1 (en) 2012-06-07
US8832175B2 (en) 2014-09-09
AU2016202239B2 (en) 2018-03-22
AU2011305494B2 (en) 2016-01-14
AU2011305494A1 (en) 2013-05-02
US9729394B2 (en) 2017-08-08

Similar Documents

Publication Publication Date Title
AU2016202239B2 (en) Methods and apparatus for allowing user configuration of dynamic endpoint generators and dynamic remote object discovery and brokerage
US10078818B2 (en) Work routine management for collaborative platforms
US8010940B2 (en) Methods and apparatus for designing a workflow process using inheritance
AU2014202725B2 (en) Methods and apparatus for translating forms to native mobile applications
US8239226B2 (en) Methods and apparatus for combining properties and methods from a plurality of different data sources
US20100153150A1 (en) Software for business adaptation catalog modeling
US20200334377A1 (en) User interface for building a data privacy pipeline and contractual agreement to share data
US20040187140A1 (en) Application framework
US8224853B2 (en) Methods and apparatus for updating a plurality of data fields in an electronic form
US20210103862A1 (en) Methods and apparatus for exposing workflow process definitions as business objects
US7996758B2 (en) Methods and apparatus for storing data associated with an electronic form
JPWO2011118003A1 (ja) ウェブアプリケーション構築システム、ウェブアプリケーション構築方法、ウェブアプリケーション構築プログラムおよびウェブアプリケーション構築プログラムを記録した記録媒体
US20070208777A1 (en) Methods and apparatus for designing a workflow process using resource maps and process maps
US20070143305A1 (en) Methods and apparatus for storing functions associated with an electronic form
US20070143711A1 (en) Methods and apparatus for displaying a setup sequence
Cozzi et al. Activity management as a web service
US20070136367A1 (en) Methods and apparatus for dynamically modifying a business object definition
US20070130138A1 (en) Methods and apparatus for storing a collaboratively designed workflow process
Keen et al. Building IBM business process management solutions using WebSphere V7 and business space
WO2016011084A1 (en) Methods and apparatus for building and deploying mobile device applications
Johannes SAP CRM: Technical Principles and Programming
KR20110024484A (ko) 확장폼을 이용한 홈페이지 제작 시스템 및 방법