All posts by n4nadm

CC RFC Receiver in Load Balancing

Per configurare il cc sulla base del SAP Logon procedere come segue

Communication Channel Editor SAP Logon
Adapter Type RFC

Receiver

Marcare Load Balancing

Message Server

Message Server

Message Server Service

“sapms”+System ID

es: sapmsIP0

System ID

System ID

Logon Group

Group/Server


SOAP

Utilizzare l’adapter SOAP senza Envelop qualora occorra inviare un messaggio HTTP in modalità POST.

In scenari webservice basati su communication channel HTTP POST invece che SOAP può essere necessario dover :

  • Aggiungere imbustamento SOAP ad un messaggio in uscita da PI
  • Togliere imbustamento SOAP da un messaggio in entrata a PI

Condizionare cc sender a cc receiver

Obiettivo

L’esigenza è quella di impedire che il file sul cc sender venga processato, e magari cancellato/archiviato, se l’elaborazione sul cc receiver va in errore.

Soluzione

Impostare la QoA sul cc sender in modalità Best Effort invece che Each Once.

In questo modo si rende sincrono l’intero processo la qual cosa comporta che:

  • L’Adapter processa il file sender (lettura e/o content conversion) e quindi viene passato all’integration engine o all’AAEx ma non viene cancellato o archiviato;
  • L’Adapter file receiver tenta la scrittura; se va a buon fine ritorna il controllo al cc sender che provvederà a cancellare/archiviare il file; se va in errore propaga l’errore al cc sender e le operazioni sul file sender si interrompono.

Strutture dati definenti ABAP Proxy

La struttura dati che definisce la service interface su cui si baserà un ABAP proxy deve sempre essere definita tramite un datatype e mai tramite un xsd; il datatype infatti, viene importato sull’ECC e dà origine ad un oggetto di dictionary. Un xsd invece resta confinato sullo stack java e questo comporta che la fase di generazione del proxy sul lato ECC va a buon fine ma viene generato un abend (ST22) in fase di run dovuto al fatto che le strutture che definiscono l’interfaccia non sono presenti nel dictionary. Uno degli  errori che può verificarsi è GETWA_NOT_ASSIGNED.


JDBC Lookup su Oracle

Il wizard di creazione dell’External Definition (dbtab) relativo alla tabella di lookup non vede la tabella in oggetto.

La ragione risiede nel fatto che all’utenza oracle utilizzata nel cc non è associato lo schema a cui la tabella appartiene.

Dal momento che il communication channel da utilizzare per la JDBC Lookup è un receiver, non è possibile associargli una query nella quale specificare lo schema Oracle; non è neppure possibile (per Oracle) indicare lo schema nella stringa di connessione JDBC.

A cura del dba, occorre far definire come schema di default dell’utenza utilizzata nel cc JDBC receiver quello a cui appartiene la tabella in oggetto.


Importare nuovo Idoc custom

Per importare un Idoc custom in PI procedere come segue:

WE31

Creare segmenti + rilascio
WE32 Creare IDoc + rilascio
WE81

Creare message type

WE82 Creare relazione message type / basic type
WE32 Creare view per IDoc

A questo punto l’IDoc può essere importato nell’ESR


Dynamic Configuration URL PlainHTTP

Assegnazione URL a cc PlainHTTP in modalità Assign Type URL Address

Assegnazione URL a cc PlainHTTP in modalità Assign Type HTTP Destination
public String PlainHTTPDestDynConf(String value, Container container) 
	throws StreamTransformationException{ 
	try { 
		String url = value; 
		DynamicConfiguration conf = (DynamicConfiguration) container .getTransformationParameters() .get(StreamTransformationConstants.DYNAMIC_CONFIGURATION); 
		DynamicConfigurationKey key=DynamicConfigurationKey.create("http://sap.com/xi/XI/System/HTTP", "TargetURL"); 
		conf.put(key, url); 
		return url; 
	} catch(Exception e) { 
		String exception = e.toString(); 
		return exception; 
	} 
}