Validierung einer Bezahlung 03

Der Validierungsprozess umfasst drei Schritte:

1. Mit der Kreditkartennummer als Schlüssel werden die Zahlungsinformationen aus der Datenbank selektiert.
    Wenn keine Daten mit dieser Kreditkartennummer gefunden werden, wird die Zahlung verweigert.

2. Wenn Daten für die Kreditkartennummer zur Verfügung gestellt werden, wird das Ablaufdatum
    des Datensatzes mit dem von Auftragsmitteilung verglichen.
    Wenn die beiden nicht übereinstimmen, wird die Zahlung auch verweigert.

3. Beim letzten Schritt wird geprüft, ob die Gesamtauftragsmenge kleiner als das Tageslimit auf
    der Kreditkarte (in der Datenbank) ist.

Wenn alle Prüfungen erfolgreich abgeschlossen wurden, wird die Zahlung autorisiert, sonst wird sie verweigert.

Um die Kreditkartendaten aus der Datenbank aufzurufen, und die gesamten Prüfungen durchzuführen
wird einen BPEL-Prozess benötigt.

Projekt-Schritte

• Erstellung einer neuen Anwendung (composite application) e2e-1201-composites und SOA-Projekt ValidatePayment.

• Nutzung einer neuen SOA-Projektvorlage (SOA Project template), um die ValidatePayment composite zu erstellen.

• Aufbau einer Datenbankverbindung zu Java DB.

• Importierung einer benutzerdefinierten Aktivitätsvorlage (custom activity template), um den Zahlungsstatus (genehmigt oder verweigert) zu bestimmen.

Die Bestimmung basiert auf dem Tageslimit und dem Gesamtbetrag der Bestellung.

• Einfügen eines zusammengesetzten Sensor PaymentStatus für den Zahlungsstatus

• Deploy des Projektes auf dem Server

• Benutzung der Debugger in JDeveloper

• Test des Projekts

SOA Templates (Vorlagen)

In SOA Suite 12c, gibt es eine Reihe von neuen Funktionen, die die gemeinsame Nutzung von gemeinsamen "Code" zwischen Teams, Abteilungen oder sogar von einem Partner verbessern.

Ein Teil davon ist die neue SOA Templates-Funktion. Wie der Name andeutet, werden sie als Ausgangspunkte für die Entwicklung von SOA-Anwendungen verwendet.

Diese Vorlagen werden entweder als Grundlage für ein Projekt verwendet oder werden sie zu einem bestehenden Projekt hinzugefügt.

Alle Änderungen, die man nach den Vorlagen-Import gemacht hat, werden nicht in den ursprünglichen Vorlagen reflektiert.

Die SOA-Vorlagen gibt es in drei Geschmacksrichtungen zu finden:

• Projektvorlagen (Project Templates): sie verfügen über ein komplettes Projekt mit allen Komponenten und Ressourcen. Man verwendet sie beim Anlegen eines neuen Projektes in SOA-Anwendung.

• Komponente -Vorlagen (Component Templates): Ein Komponent mit allen Referenzen und Ressourcen.

Beispielsweise kann ein BPEL-Prozess, der eine Geschäftsregel (Business Rule) oder Adapter aufruft als Komponent-Vorlage verpackt werden. Das Komponent muss nicht vollständig sein und muss auch nicht kompiliert sein. Eine Komponent-Vorlage kann zu einem bestehenden Projekt hinzugefügt werden.

Komponent-Vorlagen werden in der Composite Palette sichtbar sein, wenn sie natürlich in der Vorlage Pfad (in JDeveloper) konfiguriert wurden.

• Benutzerdefinierte Aktivitätsvorlagen (Custom activity templates): Ein Bereich in einem BPEL-Prozess, wo einen Partnerlink aufgerufen werden könnte, könnte als benutzerdefinierte BPEL Aktivität verpackt werden.
  Custom activity templates könnte Zum Beispiel eine Aktivität -Zuordnung und einen Adapter Aufruf sein. Diese kundenspezifischen Aktivitäten werden in der BPEL-Palette verfügbar sein

Wer mehr über Templates lesen möchte, hier ist das Link dafür:

http://docs.oracle.com/middleware/1213/soasuite/develop-soa/soa-templates.htm#BABBBIHH

<< Zurück                       Weiter >>