Dettagli interni del processo TAL
IMAN supporta un concetto a cascata di determinazione dell'identità dell'oggetto nonché di proprietà e di priorità di proprietà. Ad esempio, le parti pubblicate da SIM vengono inviate nell'elemento referencedParts.xml e ogni parte presenta un URI univoco e persistente. Quando le parti vengono inviate da SAP, sono prive dell'URI. IMAN gestisce la discrepanza fornendo i mezzi per dichiarare gli attributi di identificazione principali (ad esempio un URI) nonché gli attributi secondari.
Nel caso delle parti, gli attributi di identificazione secondari sono costituiti dal numero della parte e da orgName. In questo modo, la stessa parte può essere risolta indipendentemente dalla relativa origine utilizzando gli attributi del business. La progettazione di IMAN consente a InService di gestire i dati provenienti da vari sistemi (SIM e non SIM) sullo stesso piano o di stabilire una priorità in base alla quale un sistema può avere la precedenza sui dati di un altro sistema o acquisirne la proprietà.
Il processo include le fasi indicate di seguito.
• Inizializzazione - Questa fase inizializza il processo di trasformazione.
Per ogni tipo:
1. Preparazione del file XLM degli attributi di identificazione per tutti gli oggetti in base al file IMANConfig.xml.
2. Passaggio del file XML degli attributi a IMANManager utilizzando l'API IMANManager.identify().
3. Generazione da parte di Transform Registry (TR) del file di registro per questo tipo.
|
In genere, questo passo viene completato come transazione singola per tutti i tipi durante l'avvio del processo TAL. Se vengono caricati più bundle contemporaneamente, è necessario assicurarsi che i flussi siano sincronizzati. Nel flusso TAL, i flussi sincronizzati vengono richiamati per garantire l'assenza di dati danneggiati. In caso contrario, è possibile che lo stesso ID venga creato per lo stesso oggetto e che finisca per generare un'incoerenza e un errore.
|
• Trasformazione:
1. Utilizzo del file di Transform Registry generato in precedenza per identificare le azioni da intraprendere, ad esempio aggiungere, aggiornare, eliminare o ignorare.
2. Popolamento della cartella DCTM_Output.
In genere questa cartella si trova in INSERVICE_WORK/DCTM_Output.
3. Generazione del file manifest per i record da aggiornare o eliminare.
4. Aggiornamento del TR con i dati di pubblicazione aggiornati.
• Convalida - Questa fase convalida i dati generati (come si presentano in DCTM_Output) dopo il processo di trasformazione.
• Caricamento:
1. Avvio dell'operazione Publish to Preview Preparation (P2PP) per caricare il bundle.
2. Al termine di P2PP, rimuovere il blocco di convalida applicato al bundle.