Oracle Fusion Middleware Blog

Deutsche Informationen rund um Oracle Fusion Middleware

WebCenbter Content–WebDav als Laufwerk mappen

leave a comment »

Gelegentlich ist ein WebDav Zugang zum Content Server nötig, um aus Anwendungen heraus über das Filesystem des Clients Inhalte in den Content Server zu laden. Normalerweise würde man hier die Desktop Integration Suite nutzen, die eine Integration in den Windows Explorer sowie in MS Office bereitstellt.

image

Das Problem ist aber, dass nicht alle Anwendungen beim File Browsing, z.B. “Speichern unter”, auf die DIS zugreifen können. Als Beispiel sei hier mal der JDeveloper erwähnt – ohne Relevanz, ob es überhaupt Sinn macht aus dem JDeveloper in den Content Server zu speichern. Es gibt viele Anwendungen, die sich beim File Browsing wie JDeveloper verhalten.

image

In diesem Falle muss man erreichen, dass ein WebDAV Zugang als Netzlaufwerk mit Laufwerksbuchstaben ins Windows eingehängt wird. Das kann man entweder über alternative WebDav Clients oder nativ über den Windows Befehl  “net use” realisieren. Die Syntax der Befehlszeile für den Content Server lautet dann:

net use [Laufwerk]: “http://[CS Host]:[CS Port]/_dav/[CS Context]/idcplg/webdav/[Folder or Library Path]/” /persistent:no /user: [Username Password]

Es gibt diverse Problemchen Seitens Windows im Umgang mit Basic Authentication. (Siehe KB2673544).  Bei alternativen WebDAV Clients muss man auf die korrekte WebDAV URL des Content Servers achten. Die Adresse in der DIS ist nicht die allgemeine WebDAV URL und daher etwas irreführend.

<DM>

Written by fmtechteam

08/07/2014 at 12:19

Veröffentlicht in WebCenter, WebCenter Content

Tagged with

SOA 12c End-to-end (e2e) Tutorial

leave a comment »

In diesem Tutorial wird ein Bestellvorgangsprozeß mit der SOA Suite 12c abgebildet.

Neue Themen in diesem Tutorial sind:

  • Quick Start Installationsprozeß – Integrierter Server
  • Alles im JDeveloper – SOA und Service Bus
  • Templates
  • Debugger, Testen
  • Rest-Services
  • Neue Adapter
  • und vieles mehr …

<KM>

Written by fmtechteam

27/06/2014 at 09:20

Veröffentlicht in BPEL, Service Bus, SOA, Uncategorized

Neue Version verfügbar: Oracle SOA Suite 12c & Managed File Transfer (MFT) 12c

leave a comment »

Seit dem 26. Juni 2014 ist die Oracle SOA Suite 12.1.3 sowie der Managed File Transfer 12.1.3 offiziell freigegeben.

Alles Wissenswerte ist hier zu finden: http://www.oracle.com/technetwork/middleware/soasuite/overview/index.html

whatsnewin12c

<KM>

Written by fmtechteam

27/06/2014 at 08:33

Veröffentlicht in Service Bus, SOA

BPM Process Spaces funktionieren nicht mehr bei eigenen Portal Erweiterungen

leave a comment »

Die Bereitstellung von eigenen TaskFlows im Webcenter Portal wird letztlich über ein fertiges JDeveloper Projekt vorgenommen, welches über die WebCenter Extensions verfügbar ist. In diesem Projekt ist ein Deplyoment Profile und ein Manifest hinterlegt, welches die Erweiterungen als Shared Library auf den Portal Server deployt.

image

Die Dokumentation hierzu ignoriert aber den möglichen Umstand, dass bereits weitere Bibliotheken in WebCenter referenziert werden, so zum Beispiel die BPM TaskFlows der Process Spaces Implementierung. Die Konsequenz daraus ist, das mit dem Erweitern des Portal um eigene TaskFows bereits bestehende Referenzen überschrieben werden und die Process Spaces nicht mehr funktionieren. In diesem Falle muss man die BPM Referenzen im Manifest zusätzlich eintragen. Das MANIFEST.MF des eigenen PortalSharedLibrary Projektes sollte dann so aussehen:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: Apache Maven
Built-By: builder
Build-Jdk: 1.6.0_20
Extension-Name: extend.spaces.webapp
Implementation-Label: 11.1.1.8.0
Implementation-Title: extend.spaces.webapp
Implementation-Vendor: Oracle
Implementation-Version: 11.1.2
Specification-Title: extend.spaces.webapp
Specification-Vendor: Oracle
Specification-Version: 11.1.1
Extension-List: bpmSpaces
bpmSpaces-Extension-Name: oracle.bpm.spaces

Nun kann man wie gewohnt seine Portal Extension deployen und behält dabei die BPM Referenzen für die Process Spaces.

<DM>

Written by fmtechteam

11/06/2014 at 16:24

Veröffentlicht in BPM, WebCenter

Neu: Pre-built Virtual Machine für SOA Suite und BPM Suite 11.1.1.7.1

leave a comment »

Diese Appliance ist nur für Testzwecke und nicht für die Produktion bestimmt!

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/vmsoa-172279.html

<Kersten Mebus>

Written by fmtechteam

14/05/2014 at 13:36

Veröffentlicht in BPM, SOA, WebCenter

Verborgener Schatz: MDS-Explorer

leave a comment »

Auf java.net gibt es einen Meta-Daten-Services (MDS) Explorer, mit dem auf das MDS zugegriffen werden kann. Mit diesem Explorer können Verzeichnisse und Dateien angelegt, gelöscht, verändert, hoch- sowie heruntergeladen, editiert, usw werden.

Homepage: https://java.net/projects/mds-explorer

<Kersten Mebus>

 

Written by fmtechteam

12/05/2014 at 09:49

Veröffentlicht in BPEL, BPM, SOA

Stabiler Betrieb von Oracle Forms-Applikationen mit Deployment Rule Sets (DRS)

with one comment

Oracle Forms-Anwendungen laufen seit vielen Jahren als Java Applet im Browser und benötigen dazu das Java Plug-In im Browser.
Anwender von Oracle Forms stehen vor dem Problem, dass sie nicht in der Lage sind, ihre Anwendungen mit jedem Update des Java Runtime Environments (JRE) zu testen. Zwar gibt es inzwischen die Möglichkeit, neue Java-Versionen als Early Access Releases vorab zu testen (z.B. https://jdk7.java.net/download.html). Dies gilt aber nicht für Security Updates, die ohne Vorankündigung veröffentlicht werden und eventuelle Seiteneffekte in den Forms-Anwendungen verursachen.

Forms-Anwender stecken gewissermaßen in einem Dilemma zwischen Sicherheit (was das Einspielen der aktuellen Security Patches erfordert) und Stabilität (was die Nutzung gründlich getesteter Java-Versionen erfordert). Eine Lösung liegt in der Nutzung der Java  Deployment Rule Sets (DRS), die seit dem JDK 7 Update 40 zur Verfügung stehen. Sie bieten u.a. die Möglichkeit, durch Regeln das Ausführen bestimmter Anwendungen mit bestimmten Java-Versionen festzulegen. Diese Lösung ist insofern auch akzeptabel, da Forms-Applikationen typischerweise im Intranet laufen und hier die Bedrohung durch Sicherheitslücken kaum gegeben ist. Für alle anderen Anwendungen kann die Nutzung der aktuellsten Java-Version oder sogar ein Blockieren der Ausführung festgelegt werden. Deployment Rule Sets können in Verbindung mit Java Applets und WebStart-Anwendungen eingesetzt werden.

Informationen zu den Deployment Rule Sets findet man an folgenden Stellen:
http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/deployment_rules.html
- https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets
https://blogs.oracle.com/java-platform-group/entry/deployment_rule_set_by_example

Die Regeln werden in einer XML-Datei (ruleset.xml) festgelegt und zur Ausführungszeit sequentiell abgearbeitet. Neben der Festlegung bestimmter Versionen der JRE können mit Hilfe von Regeln u.a. auch Warnungen unterdrückt sowie die Ausführung von Anwendungen blockiert werden.

Es folgt eine Beschreibung der wesentlichen Schritte zum Einrichten eines Deployment Rule Sets (DRS) zum Ausführen einer Forms-Applikation mit einer bestimmten festgeschriebenen Version der JRE. Da ich nicht auf ein kommerzielles Zertifikat zurückgreifen konnte, entstand der größte Aufwand bei der Erstellung und Einbindung eines eigenen Zertifikats. Auf dem Arbeitsplatz muss eine aktuelle Java-Version (JRE > Java 7 Update 40) installiert sein, die das DRS erkennt und ausführt. Diese startet dann eine zweite Java-Version (dies kann auch eine JRE 6 sein), mit der die Forms-Applikation ausgeführt wird.

  1. URL oder Hash Sign der Anwendung ermitteln, für die eine Regel festgelegt werden soll. Im Falle von Oracle Forms wäre dies z.B. die folgende URL: http://jmenge-de.de.oracle.com:7001/forms/frmservlet.
  2. Anlegen einer Datei ruleset.xml zum Beispiel mit folgendem Inhalt:
    <ruleset version="1.0+">
      <rule>
        <id location="http://jmenge-de.de.oracle.com:7001/forms/frmservlet" />
        <action permission="run" version="1.7.0_25"/>
      </rule>
      <rule>
        <id />
        <action permission="block" />
      </rule>
    </ruleset>
    

    Die Regeln bewirken, dass die Forms-Anwendungen (URL) immer mit der Version 1.7.0_25 ausgeführt werden. An dieser Stelle kann aber auch eine ältere Java-Version (JRE 6) aufgerufen werden.
    Alle anderen Anwendungen (Applets, Java WebStart) werden durch die zweite Regel blockiert.

  3. Die Datei ruleset.xml muss in ein jar-Archiv mit dem Namen DeploymentRuleSet.jar gepackt werden. Dies erfolgt mit dem Befehl:
    jar -cvf DeploymentRuleSet.jar ruleset.xml
    Wichtig ist, dass sich alle Dateien im gleichen Verzeichnis befinden. Die Datei ruleset.xml darf nicht mit einer Pfadangabe im Archiv stehen.
  4. Als nächstes muss das jar-Archiv signiert werden. Das erforderliche Zertifikat kann von einer Certificate Authority (CA) angefordert oder selbst erstellt werden.
    Eine Anleitung zur Signierung mit einem eigenen Zertifikat findet man hier:
    https://blogs.oracle.com/java-platform-group/entry/self_signed_certificates_for_a
    Das signierte jar-Archiv kann anschließend mit dem Befehl
       jarsigner -verify DeploymentRuleSet.jar
    überprüft werden.
  5. Das jar-Archiv muss in ein bestimmtes Verzeichnis auf dem Desktop des Endanwenders kopiert werden. Bei einem MS Windows-System heißt dieses Verzeichnis:
    <Windows Directory>\Sun\Java\Deployment
    und wird in der Regel neu anzulegen sein.
    In der Java Console (Tab Security) kann man jetzt überprüfen, ob das Deployment Rule Set auch tatsähchlich erkannt wurde.
    JavaConsole
  6. Zum Testen muss man jetzt nur noch die Forms-Anwendung übr die festgelegte URL aufrufen.
    Zunächst wird die aktuelle (d.h. sicherste) Version der JRE gestartet. Diese interpretiert das Deployment Rule Set und ruft auf Grund unserer definierten Regel eine ältere (getestete) Version des JRE auf. Dies kann man sehr gut im System Tray von MS Windows erkennen, da nach erfolgreicher Ausführung dort zwei Java-Icons zu sehen sind.
    SystemTray
    Schlägt der Aufruf fehl, geben die Fehlermeldungen einen Hinweis auf die Ursache (z.B. Can not verify self-signed DeploymentRuleSet.jar.).

Wir haben damit erreicht, dass die internen Forms-Anwendungen mit einer stabilen und getesteten Version der JRE ausgeführt werden. Rufen die Anwender eine andere Anwendung (Applet, Java WebStart) im Browser auf, wird die aktuellste Version der JRE verwendet oder wie in unserem Beispiel die Ausführung blockiert.
Die Verwendung der Deployment Rule Sets ist in Verbindung mit Oracle Forms-Anwendungen offiziell supported.

<JM>

 

Written by fmtechteam

07/05/2014 at 11:54

Veröffentlicht in Forms, Java

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.