Eigener Modus für RFC-Call (Singleton)
2 Beiträge
•
Seite 1 von 1
2 Beiträge
Seite 1 von 1
Hallo,
ich muss von einem Fremdsystem (Non-SAP) einen RFC-Fuba in meinem CRM 4.0 (WebAS 6.20) asyncron aufrufen.
Dabei soll für den User ein eigener Modus erzeugt werden, dieser aber bei dem nächsten RFC-Call wieder überschreiben werden.
D.h. es gibt für mich 2 Möglichkeiten:
a) ich rufe es so auf, dass ich wieder den alten Modus treffe (also quasi ein Singleton)
b) ich erstelle einfach noch einen Modus und beende den alten
Was könnt ihr mir hier empfehlen?
Zur Ausgangslage:
Es handelt sich dabei um ein Java bassiertes e-Mail Programm und jeweils beim Anklicken der Mail soll im CRM schon mal ein Prozess starten und die Mail analysieren. Allerdings wird der User evtl. uch erst mal alle Mails nacheinander lesen, bevor er sch wirklich entscheidet, welche Mail er bearbeitet.
Um das ganze zu simulieren rufe ich den Fuba im Moment von einem anderen SAP-System aus auf:
Dabei wird allerdings jedes mal ein neuer modus gestartet und der alte nleibt weiter bestehen.
Was könnte man da anders machen?
ich muss von einem Fremdsystem (Non-SAP) einen RFC-Fuba in meinem CRM 4.0 (WebAS 6.20) asyncron aufrufen.
Dabei soll für den User ein eigener Modus erzeugt werden, dieser aber bei dem nächsten RFC-Call wieder überschreiben werden.
D.h. es gibt für mich 2 Möglichkeiten:
a) ich rufe es so auf, dass ich wieder den alten Modus treffe (also quasi ein Singleton)
b) ich erstelle einfach noch einen Modus und beende den alten
Was könnt ihr mir hier empfehlen?
Zur Ausgangslage:
Es handelt sich dabei um ein Java bassiertes e-Mail Programm und jeweils beim Anklicken der Mail soll im CRM schon mal ein Prozess starten und die Mail analysieren. Allerdings wird der User evtl. uch erst mal alle Mails nacheinander lesen, bevor er sch wirklich entscheidet, welche Mail er bearbeitet.
Um das ganze zu simulieren rufe ich den Fuba im Moment von einem anderen SAP-System aus auf:
Code: Alles auswählen.
CALL FUNCTION 'Z_RFC_START'
STARTING NEW TASK 'myTask'
DESTINATION 'XYZCLNT100'
EXPORTING
x_email = l_email
x_datum = l_datum
x_zeit = l_uzeit
x_mail = l_mail
EXCEPTIONS
OTHERS = 1.
Was könnte man da anders machen?
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
so, ich hab nun ne einigermaßen machbare lösung...
Aufruf des Fubas aus Java mit dem RFCUSER
anschließend löschen der benutzer mit rfc-modus
aufruf eines neuen fubas mit neuer destination.
bei dieser destination wird der eigentliche user hinterlegt. so spart man sich auch gleichzeitig das passwort, wenn es ein trusted system ist
nachteil:
es muss pro user eine destination in der sm59 angelegt werden.
Aufruf des Fubas aus Java mit dem RFCUSER
anschließend löschen der benutzer mit rfc-modus
Code: Alles auswählen.
** Restliche RFC-Verbindungen beenden
CALL FUNCTION 'TH_USER_LIST'
TABLES
list = lt_user.
DELETE lt_user WHERE bname <> x_user.
LOOP AT lt_user INTO ls_user
WHERE type = '32'.
CALL FUNCTION 'TH_DELETE_USER'
EXPORTING
user = ls_user-bname
client = sy-mandt
only_pooled_user = ' '
tid = ls_user-tid
EXCEPTIONS
authority_error = 1
OTHERS = 2.
IF sy-subrc <> 0.
* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
ENDLOOP.
bei dieser destination wird der eigentliche user hinterlegt. so spart man sich auch gleichzeitig das passwort, wenn es ein trusted system ist
nachteil:
es muss pro user eine destination in der sm59 angelegt werden.
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
2657
Views
Views
11
Antw.
Antw.
6422
Views
Views
1
Antw.
Antw.
2803
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
just
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.