---

Hallo Liebe Forianer,

wir haben Solid Edge V18 mit dem aktuellsten Servicpack im Einsatz.
Dieses wird mit einer Direktintegration über Gedas betrieben.
Unser Problem ist nun daß beim Einchecken einer Baugruppenfamilie die Dokumenteninfosätze nicht in die Dateieigenschaften mit abgelegt werden.
Was bedeutet, beim auschecken der Familienbaugruppe aus dem KPRO sagt die Gedas Schnittstelle, dass die Datei mit den Dokumenteninfos nicht gefunden werden konnte.
Komischerweise werden die Dokumenteninfos beim konstruieren lokal auf C:\ abgelegt, danach aber nicht mit in den KPRO wandern.
Wenn ein Konstrukteur jetzt auf seiner Platte klar Schiff macht und diese Datei löscht, bekommt er diese Fehlermeldung.
Ebenso wenn ein Kollege die Baugruppenfamilie öffnet.
Bei "normalen" Baugruppen ist die seltsamer weise nicht der Fall.....

Unser Dienstleister sagt es liegt am SAP Release Stand (SAP/R3 4.6C), es wäre mit diesem Release nicht möglich.

Hat von Euch jemand das selbe Problem?
Arbeitet sonst jemand mit SE und Gedas und der Direktintegration?
Welche Erfahrungen habet Ihr?

Vielen Dank,
viele Grüße,
MeierJ

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Dazu kann ich nichts sagen, das Thema Direktintegration in SAP interessiert mich aber brennend. Ich stehe nämlich vor der Wahl zwischen einer Direktintegration und einer alternativen Integration zbsp. über Teamcenter. Dazu such ich auch noch Leute mit praktischen Erfahrungen.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus MeierJ,

vielleicht hilft Dir diese Info:
Bei FOAs werden die DIS Daten nicht in den Dateieigenschaften sind in einer Textdatei (Endund plminfo) gespeichert.
Ich wundere mich schon seit Jahren darüber.

Jürgen

------------------
141*SEV18SR12, 12*SEV19SR9

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen,
ja genau, das habe ich auch schon gesehen/bemerkt...
Warum denn so was, ich brauche doch die Infos im KPRO und nicht lokal auf der Platte.

Gibt es da keine Lösung?

Gruß (auch) Jürgen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Wieso brauchst Du die Daten im KPRO? Wenn Du die Daten über die Schnittstelle auscheckst werden doch die Properties gefüllt bzw. die plminfo-Datei erzeugt. Was binär im KPRO liegt sieht doch keiner.

Klar darf mit dieser Regelung keiner einen Doppelklick auf das Original im DIS machen, da sonst die Properties nicht stimmen. Ist ja auch im Sinne des Erfinders, man soll ja auch für jeden, auch die Leute in der Fertigung, die die SE-Dateien nur viewen eine Schnittstellen Lizenz ordern.

Jürgen

------------------
157*SEV19SR09, 4*SEV20SR0

[Diese Nachricht wurde von Jürgen Niesner am 18. Okt. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen!

Jetzt kommen wir der Sache schon mal näher.....
Die plm Info Datei wird bei uns nicht erzeugt (Beim auslesen der Datei aus dem KPRO) und somit auch nicht mit den Properties befüllt.

Warum denn das?

Jetzt meine Frage an Dich... was für einen Release Stand hast Du im SAP?
Kann es dran liegen?

Hast Du eine Idee?

Vielen Dank für Deine Hilfe,
Gruß Jürgen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Servus Jürgen,

wir haben folgenden Stand

Cideon-Schnittstelle
sapse.dll 4.8.72.0
SeGeSAP.dll 1.8.58.40

SAP-GUI
SAP GUI 640 Final Release Patch-Level 22 Dateiversion 6405.5.22.3036

SAP-SYSTEM
SAP BASIS 640 0018
SAP_APPL 500 0011
EA-APPL 500 0011

SolidEdge
SE V19 SR9 dt / SE V20 SR0 dt

Jürgen

------------------
157*SEV19SR09, 4*SEV20SR0

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen,

vielen Dank für Deine schnelle Antwort und Info's.
Ihr habt das Problem denke ich nicht oder?
Das gibts doch nicht, da wird ein Vermögen ausgegeben und nachher so was.....

Viele Grüße,
Jürgen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen,

ich sehe das auch so wie Jürgen. Die plm Info Datei wird nicht im KPRO abgelegt. Sie wird jedes mal beim Laden über den CAD-Desktop oder die Integration neu erzeugt. Das Laden der Dateien darf auf keinen Fall über den DIS direkt erfolgen, da dort diese Info Datei nicht erzeugt wird!
Da die plm Info Datei immer neu erzeugt wird, ist vermutlich der Fehler an der Schnittstelle bzw. an den entsprechenden DLLs zu suchen. Die Dlls sind für diese Aufgabe zuständig.

Viele Grüße
Klaus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,
kann es evtl. am Release Stand in SAP liegen?
Wir haben es extern gehostet, jetzt habe ich die Info bekommen was wir haben:

SAP_BASIS  620  0034  SAP Basiskomponente
SAP_APPL    470  0017  Logistik und Rechnungswesen
EA-APPL    110  0015  SAP R/3 Enterprise AddOn PLM, SCM, Financials

Der Releasestand scheint mir weit ninter dem von Jürgen (oben) zu sein.

Vielen Dank für Eure Hilfe,
viele Grüße,
Jürgen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi, das könnte der Grund sein.

Hier mal unseren Stand.
Release 700 Patch 124

SAP_BASIS 700 0011
SAP_APPL 600 0008
EA_APPL 600 0008

cya
AMG

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen,

wir haben auch einen wesentlich aktuelleren Stand.
SAP_BASIS 700 0012
SAP_APPL 600 0010
EA_APPL 600 0010.

Die Baugruppenfamilien waren nicht von Anfang an in Solid Edge. Ggf. könnte es sein, dass Eure Version die Baugruppenfamilien noch gar nicht unterstützt!? Wobei es eigentlich auch für die älteren Versionen entsprechende Updates gibt.
Seit Ihr mit Eurem Stand aktuell, oder gibt es neuere Patchlevels?

Die installierten Versionen kannst Du Dir übringens auch selber anzeigen lassen. Im SAP normal (ohne CAD) anmelden. Im Menü System den Unterpunkt Status auswählen. In der Statusübersicht gibt es auf der rechten Seite eine Icon mit Lupe. Dort sind die Releasedaten versteckt.

Gruß
Klaus

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,

jetzt habe ich den Patchlevel:
==============================================================
SAP_BASIS: Release: 620, Level: 0034, Höchstes Support Pakage: SAPKB62034
==============================================================
SAP_APPL: Release: 470, Level: 0017, Höchstes Support Pakage: SAPKH47017
==============================================================
EA-APPL: Release: 110, Level: 0115, Höchstes Support Pakage: SAPKGPAA15

Dieser Stand ist zu niedrig.... oder?
Vielen Dank für Eure Hilfe.

Gruß meierj

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

ich traue mich einfach zu behaupten, dass wir bei diesem Versionsstand die plminfo-Datei auch schon bekommen hatten.
Es liegt vermutlich auch nicht am SAP-System, sondern an der Schnittstellenversion der gedas/Cideon-Dlls.

Jürgen

------------------
157*SEV19SR09, 4*SEV20SR0

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Jürgen,
die dll's sind in den Versionsständen
================
Cideon-Schnittstelle
sapse.dll 4.8.72.0
SeGeSAP.dll 1.8.58.40
=====================

genau identisch wie diese von Dir!
Daran kann es denke ich nicht......

Viele Grüße,
Jürgen

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ich tippe nach wie vor darauf das es am Client liegt. Evtl. an den Einstellungen.

Die Schnittstelle kann die DIS-Daten aus SAP lesen, weil es ja bei normalen ASMs und alle andere SE-Dokarten auch geht. SAPseitig werden normale ASMs und FOAs bei uns gleich behandelt, ich denke nicht das in der Schnittstelle da kundenspezifische Unterschiede implementiert sind.
Das Problem muss also am Schreiben der Daten in die SE-Dateieiegenschaften oder beim Erstellen der plminfo-Datei liegen.

ich habe Dir eine PM geschickt mit meiner eMail-Adresse. Schick mir mal Deinen gedas-Reg-Key, den importioer ich dann mal bei mir und teste ob ich dann noch plminfo-Dateien bekomme.

Jürgen

------------------
157*SEV19SR09, 4*SEV20SR0

[Diese Nachricht wurde von Jürgen Niesner am 25. Okt. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo FOA-Anwender,

zum Thema FOAs. Ich habe seit geraumer Zeit mit FOAs zu tun. Ich glaube, wenn man Infos für ein FOA speichern möchte, hat man keine andere Chance, als sie extern zu verwalten. Macht mal Folgendes. Erstellt ein FOA in SE, danach FOA schließen. Dann selektiert die Datei im Explorer, rechte Maustaste auf Eigenschaften und den Reiter „Benutzerdefiniert“ auswählen. Jetzt einfach mal eine Eigenschaft erstellen. Nun das FOA wieder in SE öffnen dort eine grafische Änderung machen, speichern und wieder schließen. Und nun schaut mal im Explorer nach, ob die Dateieigenschaft noch da ist. Sie ist es nämlich nicht mehr.
Da es bei uns in der Firma das gleiche Problem gab, wie speichere ich Infos an einen FOA, habe ich die FOAs auf Binär-Ebene analysiert. Den Eigenschaften-Container gibt es bei FOAs nicht. Beim Erstellen einer Eigenschaft mit dem Explorer (wenn kein Container da ist zeigt der Explorer trotzdem einen Reiter bei Komponentdateien an) wird er vom Explorer erstellt. Wird das FOA danach in SE geändert, dann löscht SE den Container beim Speichern einfach wieder.
Es ist aber so, das jeder Member einen eigenen Eigenschaften-Container hat. Dieser liegt hierarchisch aber eine Ebene tiefer. Diesen Container kann der Explorer nicht anzeigen. Er müsste ja auch für jeden Member einen anzeigen. Die Überlegung die Infos in den Containern der Member zu speichern, schlug auch fehl. Man kann immer nur Infos in den Container des aktiven Members speichern. Weil ja immer ein anderer Member in einem geöffneten FOA aktive sein kann, müsste man die Infos in allen Membern speichern. D.h. ggf. bei 20 Membern, 20 Member aktivieren. Das wäre jedes Mal ein wildes Bildschirmgeflacker. Zum Ändern, wenn ich drei neue Member einfügen und gleichzeitig die alten 20 lösche, ist die Info verloren, da es dazu keine Event-Meldung von SE gibt.
Ich hoffe, die Infos helfen euch einwenig zu verstehen, warum bei FOAs nur so vorgegangen werden kann. Ich bin aber trotzdem für jede andere Idee offen.

------------------
Viele Grüße
Paul

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Moin,

[...]
Den Eigenschaften-Container gibt es bei FOAs nicht.
[...]

doch, er ist vorhanden wird aber offenbar nur als Platzhalter benutzt in die
beim Einfuegen der FOA in eine ASM die entsprechnenden Benutzter-Def.
Eigenschaften des ausgewaehlten Members kopiert werden. Damit wuerde
dann die interne Logik zur Abfrage der Eigenschaften auf ASM-Ebene erhalten
bleiben egal ob nun die eingefuegte ASM ein FOA-Member ist oder nicht.
Eine FOA hat also einen Standard Stream (immer leer) und je Member einen
Stream, der beim Anlegen jeweils vom 'Master' kopiert wurde. Der
Stream des 'Masters' wird beim Save dann geleert.

Anders verhaelt es sich bei FOP, dort hat der Master und jedes
Member (da eigene Datei) nur den entsprechenden Stream in der Datei.
Beim erstmaligen Anlegen eines Members wird der Stream des Masters
(Custom) kopiert. Spaetere Aenderungen werden nicht mehr fuer die
Member wirksam.

Alles in allem: eine uebliche Programmiertechnik ist hier wohl angewandt worden.
Nur an der geschilderten Problematik aendert es auch nichts ...

Klaus

------------------
Lieber Fehler riskieren als Initiative verhindern (R. Mohn)

[Diese Nachricht wurde von modeng am 02. Nov. 2007 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Klaus und alle FOA-Begeisterte,

also mein Wunsch ist es dem FOA eine Eigenschaft zu verpassen, die nur für das FOA gilt, weil mich die Datei interessiert und nicht die einzelnen Member. Diese Dateieigenschaft möchte ich auch jederzeit ändern können. Und das ist mir bis Heute nicht gelungen.

Deine Aussage Klaus ist richtig, das beim Erstellen eines FOAs aus einer normalen ASM-Datei alle Dateieigenschaften die diese ASM-Datei zu dem Zeitpunkt besitzt in die Eigenschaften jedes neu erstellten Members kopiert werden. Jeder weitere neu erstellte Member enthält diese Eigenschaften egal wann der Member erstellt wird. Möchte ich diese Eigenschaften aber in nachträglich neu erstellten Membern nicht haben, dann muss ich sie in jedem Member einzeln löschen. Die Check-Box, alle Member gleichzeitig ändern, hat da keine Wirkung.
Es sei denn, ich ändere die Eigenschaften mit dem Revision Manager. Damit kann ich die Eigenschaften im Master und im erst erstellten Member der Datei ändern. Wobei der Revision Manager die Eigenschaften des als erstes erstellten Members anzeigt. Also alle anderen Member sind von der Änderung nicht betroffen. Wird nun ein neuer Member erstellt, dann erscheint die im Master gelöschte Eigenschaft nicht mehr. Habe ich im erst erstellten Member eine Master-Eigenschaft in SE gelöscht, dann werde ich diese Master-Eigenschaft im Master nie wieder über Menü-Funktionen los, es sei denn, ich müsste den erst erstellten Member löschen, dann würde der zweit erstellte Member die Position des erst erstellten einnehmen. Man kann auch beobachten dass eine Änderung von Eigenschaften in einem Member in SE diese Änderung sofort auf die Platte schreibt (nach dem Schließen des Eigenschaftenfensters hat sich das Änderungsdatum der Datei geändert). Schließt der Anwender die Datei ohne zu Speichern, Pech gehabt, die Änderungen sind schon gespeichert.
Beim Einfügen eines FOAs in z.B. eine ASM-Datei, wird immer nur ein Member eingefügt. Der Pointer dieser Datei liefert mir nur die Eigenschaften des Members. Der Pointer der Datei liefert mir aber nicht den Pointer auf den Master, wobei ich mit SE-API-Funktionen nicht schreibend an die Eigenschaften des Masters komme, wenn die FOA-Datei direkt offen ist.

Für mich existieren z.Z. nur zwei Lösungen:
- Infos in einer separaten Datei pflegen
- Die Eigenschaften im Master des FOA mit Revision Manager ändern. Ist das FOA aber in SE zum Schreiben offen, dann muss die Datei jedes Mal geschlossen und danach wieder geöffnet werden, sonst Fehler mit einer Schutzrechtsverletzung. Da freut sich doch der Anwender. Wurde ein FOA in eine ASM-Datei eingefügt, dann ist die FOA-Datei, wenn sie aktive ist schreibgeschützt geöffnet. Schaut sich der Anwender die Dateieigenschaften des FOAs mit rechter Maustaste – Menü an, dann ist die Datei danach zum Schreiben offen (ohne eigenem Fenster, Datei kann nicht im Explorer gelöscht werden).In diesem Fall muss man auch zusehen, das man diese Datei vorher wieder zu bekommt. Also Alles nicht so richtig akzeptabel.

Übrigens, Hut ab vor den FOA-Anwendern, die mit der Funktionalität klar kommen. 

So sieht die Struktur eines normalen Assemblies aus:
Assembly.asm
    |_ Property-Container

So sieht die Struktur eines FOAs aus:
FOA.asm
    |_ Master
        |_ Property-Container
    |_Member1
        |_ Property-Container
    |_Member_n
        |_ Property-Container

[…]
Der Stream des 'Masters' wird beim Save dann geleert.
[…]

So ist das nicht. Der Stream wandert hierarchisch nur eine Stufe tiefer. Mit dem Explorer kann man nun parallel zu Master und Member ein Property-Container (Stream) erstellen. Wird das FOA danach in SE geöffnet, wird dieser Stream aber einfach ignoriert. Beim Speichern der FOAs wird die oberste Ebene neu erstellt und der Master und alle Member neu herausgeschrieben (egal ob an jedem Member etwas geändert wurde). Deshalb dauert das Speichern bei FOAs auch so lange. Und der Stream auf oberster Ebene wird einfach nicht erstellt.
Beim Erstellen eines neuen Members in SE wird nun einfach in den zugehörigen Property-Container eine Kopie des Master Property-Container gespeichert.

An den Property-Container vom Master kommt man nur über die Revision Manager-API bzw. MicroSoft-API ran. Wobei die Datei in SE nicht zum Schreiben offen sein darf.

------------------
Viele Grüße
Paul

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP