BOfH_666

Für's Arbeiten mit Excel-Dateien ist das Modul von Doug Finke ImportExcel empfehlenswert. Ob man damit auch Excel mit einer bestimmten Datei in einer bestimmten Zelle starten kann, weiß ich nicht.

... is keine blöde Frage (auch wenn das Fragezeichen fehlt ) ... und "ja", dann gibt's ne Fehlermeldung oder die bereits existierende Datei wird überschrieben ... je nach dem, wie Du's in Deinem Code gemacht hast. Nö ... ... wie oben schon nebenbei erwähnt ... ich mag kein XML und deshalb würde ich's für mich so einfach wie möglich halten wollen. Was mir spontan einfällt, wäre, einfach ein weiteres Merkmal des XML-Knotens heranzuziehen, um den Dateinamen wieder eineindeutig zu machen. Wie Du hoffentlich im Code erkannt hast, prüfe ich in der Schleife nicht auf irgendwas, sondern nehme einfach einen Node nach dem anderen und behandle alle gleich. Wenn also wie in Deiner neuen XML-Datei die LEI nicht genügt, dann nimmst Du "Test 4" oder "Birne" dazu und schon ist wieder alles eindeutig. siehe einen Absatz weiter oben.

Erzähl mir was Du willst ... ich bleibe dabei ... XML is weder einfach noch intuitiv und definitiv is XML nix für mich! $startFolder = 'D:\sample' $inputXML = 'TestXML.xml' $inputXMLFile = Join-Path -Path $startFolder -ChildPath $inputXML $xml = [xml](Get-Content $inputXMLFile) Foreach ($ChildNode in $xml.SctiesFincgRptgMssngCollReq.TxId) { $CurrentXMLFileName = Join-Path -Path $startFolder -ChildPath ($ChildNode.RptgCtrPty.lei.ToString() + '.xml') $NewXML = New-Object System.Xml.XmlDocument $declaration = $NewXML.CreateXmlDeclaration("1.0", "UTF-8", $null) $NewXML.AppendChild($declaration) $RootNode = $NewXML.CreateNode('element', 'SctiesFincgRptgMssngCollReq', $null) $NewXML.AppendChild($RootNode) $NewElement = $NewXML.ImportNode($ChildNode, $true) $Root = $NewXML.SelectSingleNode('SctiesFincgRptgMssngCollReq') $Root.AppendChild($NewElement) $NewXML.Save($CurrentXMLFileName) }

Du gönnst uns also zum Testen nicht mal eine XML, die wenigstens mal 2 oder 3 der Knoten enthält, von denen Du dann in der resultierenden XML nur noch einen behalten willst ....

Mit 64k warst Du ja schon privilegierter ISDN-Nutzer. Modem ging nur bis 56k!! (oder so in der Gegend)

Na Du bist ja putzig .... dafür ist so ein Forum doch da ... ... und Du bist nicht der Einzige, der hier was lernt.

Komisch - JSON finde ich irgendwie deutlich zugänglicher als XML. ... genau wie YAML. Vermutlich sehen das ja auch viele andere so ... sonst wär's ja nicht so populär, oder? ... oder nicht so schnell so populär geworden. XML hatte ja lange genug sein Chance. Aber wenn mir dieser ominöse Jemand das wirklich erst kurz vor meinem letzten Arbeitstag vor die Füße wirft, dann mach da ich einen g r o ß e n Schritt drüber und sitze das einfach aus.

Einmal genügt völlig. ... ich bin auch eher der "Softwareverteilung vor GPO" - Mann, aber das hat ja nu auch nicht jeder zur Verfügung. ... da dachte ich .... ok, dann vergess' ich das gleich wieder.

... 'is eher ne Abneigung als ne Phobie. ... und sooo wahnsinnig einfach isses wohl dann doch nicht - sonst würden sich nicht so viele Leute damit so schwer tun ... ... meine Vermeidungs- / Umgehungs-Strategie hat bisher ganz gut funktioniert. Lesen und Benutzen klappt - Bearbeiten musste ich bisher nie. Vielleicht schaff' ich's ja noch bis zur rente mich drumrum zu mogeln.

Nur mal so 'ne Idee ... den Anwender-Programmen einfach die komplette Antwort-Datei zu verfüttern funktioniert nicht? Könnte ja sein, dass das Programm so intelligent ist, sich die passende Info rauszusuchen ...

Wow. Respekt. Also bei der Reaktionszeit - und nicht nur da - macht Euch echt absolut niemand etwas vor. Ein riesengroßes Dankeschön für euren Einsatz.

OK, dann versuche ich mal, das Ganze in Prosa zusammenzufassen: Ihr habt eine Software, die für jeden Nutzer einzeln eine Datei irgendwohin verschickt, die für einen Validierungsprozess benötigt wird. Als Antwort für die einzeln verschickten Dateien, erhaltet ihr eine zusammengefasste Antwort-Datei, die die gesammelten "Antwort-Datensätze" für die einzelnen Anwender enthält. Diese zusammengefasste Antwort-Datei muss jetzt in einem manuellen, externen, aufwändigen Prozess so aufbereitet werden, dass sie von den einzelnen Anwendern wieder als Abgleich verwendet werden und vom Programm eingelesen werden kann. Ist das erforderliche Format irgendwie dokumentiert? Hab ich das soweit richtig verstanden? Habt Ihr für die Software Geld bezahlt? Falls ja, würde ich entweder auf Minderung des Preises oder auf Nachbesserung bestehen. ... mal ernsthaft, wenn das so ist, kann das nicht im Sinne des Erfinders sein. Achso ... wenn CSV-Dateien nicht gehen, änderst Du einfach die Endung auf txt und hängst die Datei so an. Mal so aus Neugier an einen Mod (falls einer mitliest): warum sind CSV-Dateien nicht erlaubt?

Neeee ... ob der Abgleich bei den Usern manuell erfolgt. Wenn die Anwender die XML-Datei einfach öffnen und mit ihren eigenen Äuglein reinschauen, um den Abgleich durchzuführen, dann wäre es meiner Meinung nach fast besser, wenn es keine XML-Dateien wären. XML-Dateien sind nicht für Menschen gemacht. (höchstens für Sadisten und Masochisten )

... und meine erste Frage?

Bitte nicht falsch verstehen ... ich bin nicht unwillig, oder so zweifle Deinen angestrebten Workflow an. Ich finde die Arbeit mit XML und Powershell nur alles andere als intuitiv und einfach und versuche deshalb, für mich so weit wie möglich zu vermeiden, wirklich mit XML arbeiten zu müssen ... also sorry dafür. Tut er das manuell? Also öffnet der User die Datei und schaut für den Abgleich hinein? Wenn das so ist, muss es ja nicht zwingend eine valide XML-Datei sein, oder? Es würde eine Text-Datei genügen, die die nötigen Informationen enthält. Was würde passieren, wenn man nur eine Datei zum validieren versenden würde? Vielleicht kann man das Aufsplitten in einzelne User-Dateien ja vermeiden, wenn man dem Validator nur einzelne User-Dateien verfüttert!? Und diese Zuordnung von User zu Nummer liegt nur in einer XLS-Datei vor? Eine CSV-Datei wäre für Powershell ein wenig einfacher zu verarbeiten.

hmmm ... ok, und was macht der User dann damit? Nimmer er einen Editor und schaut rein? Wer erstellt die XML-Files zur Validierung? Warum kommt nur eine Response-Datei zurück und nicht für jeden User eine? Woher kommen die Nummern für jeden User? ... vielleicht aus dem AD?

Hmmm ... das hatte ich verstanden, aber wozu? Was willst Du mit den neu erzeugten Dateien anstellen? Genau genommen brauchst Du die Schleife bei Powershell nicht mal. Wenn Du die ID's nur ausgeben willst, reicht auch das hier: $StatXmlData.SctiesFincgRptgTxStatRpt.TradData.ChildNodes

Ich bin weit davon entfernt XML wirklich zu verstehen. Und ich bin noch viel weiter davon entfernt, ein Fan von XML zu sein. Wenn irgendwie möglich mache ich einen riesengroßen Bogen um XML. So ... da das XML-Schnipselchen, welches Du gepostet hast, kein valides XML ist und man es so nicht verwenden kann, hab ich es mal auf etwas Benutzbares eingekürzt. <?xml version="1.0"?> <SctiesFincgRptgTxStatRpt> <TradData> <Stat> <TechRcrdId>ERTHUTDREPxxSCDxxSFTRxxSFTxx487331</TechRcrdId> </Stat> <Stat> <TechRcrdId>WKTHUTDREPxxSCDxxSFTRxxSFTxx487335</TechRcrdId> </Stat> <Stat> <TechRcrdId>KRTHUTDEKDxxSCDxxSFTRxxSFTxx487339</TechRcrdId> </Stat> </TradData> </SctiesFincgRptgTxStatRpt> Angenommen, wir haben das in der Datei D:\sample\test.xml gespeichert, können wir mit folgendem Code die einzelnen TechRcrdId's auslesen. $StatXmlData = [xml](Get-Content D:\sample\test.xml) $node = $StatXmlData.SctiesFincgRptgTxStatRpt.TradData.ChildNodes foreach ($entry in $node){ $entry } Was möchtest Du denn mit den extrahierten Daten anstellen? Hier noch ein bissl Lektüre zum Thema XML mit Powershell: https://www.petri.com/creating-custom-xml-net-powershell oder hier: https://searchwindowsserver.techtarget.com/tip/Using-PowerShell-to-create-XML-documents oder hier noch was vom Dr. Tobias: https://www.powershellmagazine.com/2013/08/19/mastering-everyday-xml-tasks-in-powershell/

.... is so.

Hmmm ... ich kann Dir nicht sagen, wie Du das mit dem Skript hinbekommst, aber ich kann Dir sagen, dass Du GPOs auch zum Dateien kopieren benutzen kannst ... ganz ohne Skript. Computer Configuration -> Preferences -> Windows Settings -> Files oder User Configuration -> Preferences -> Windows Settings -> Files

Hmmm .... das sollte mit einer VM genau so gehen, wie mit einem physischen Server. Du kannst dann nur nicht mehr per RDP drauf zugreifen. Du solltest aber vom Hypervisor eine "Konsolen-Session" starten können und so darauf zugreifen können.

Hmmmm ... das glaube ich nicht. Ohne die Option /MT läuft robocopy im Single Thread Modus. Mit Option /MT aber ohne Angabe einer Anzahl werden 8 Threads bentutzt. Mit der Option /MT mit einer Zahl zwischen 1 und 128 werden die angegebenen Threads benutzt. Jedenfalls laut der robocopy Hilfe.

Ist der Performance-Gewinn durch die /MT Option denn wirklich so hoch, dass ihr darauf nicht verzichten könnt/wollt?

Hast Du denn verifiziert, dass es auch wirklich an robocopy liegt? Hast Du mal versucht, die betroffenen Dateien mit einem anderen Tool - notfalls einfach mit dem Windows-Explorer - zu transferieren? Es ist ziemlich unwahrscheinlich, dass robocopy nur einen bestimmten Dateityp nicht korrekt kopiert. Hast Du die Dateien in Quelle und Ziel mal per Check-Summe geprüft/verglichen? Mit Powershell Get-FileHash brauchst Du nicht mal ein externes Tool.

Hier noch mal der Tipp, den Code etwas einfacher lesbar zu machen ... $CredPassword = ConvertTo-SecureString "aaaaa" -AsPlainText -Force $cred = New-Object System.Management.Automation.PSCredential "bbbbb", $CredPassword $SenMailParams = @{ To = '1234@5678.de' Subject = 'HyperV-Replica Alarm' Body = Get-Content $Info_Datei | Out-String SmtpServer = 'ddddd' From = 'Admin@ccccc' Credential = $cred } Send-MailMessage @SenMailParams Der Code macht das Gleiche wie Dein Code ... es ist, wie ich glaube, nur einfacher zu lesen. Der SMTP-Port ist im Standard sowieso 25. Den musst Du nur angeben, wenn er NICHT 25 ist. Kannst Du diesen Schnipsel denn von dem Rechner aus erfolgreich ausführen, von dem das Script laufen soll?