PHP-Nuke Download Section vs. FileBase
How to import from Filebase ...
- Section 5 - Umsetzung des TIC Imports
[29.1.06]
Weiterentwicklung wieder aufgenommen ....
- *** Solution mit existierender DLIMP DB
* php script to read fareas.fix into sql table
* record length: 2535
| h1line_ | = | readblock[2535] |
| |
| ltag_ | = | asc( substr(h1line_,1,1) ) |
| tag_ | = | substr(h1line_,2,ltag_) |
| lcomment_ | = | asc( substr(h1line_,55,1) ) |
| comment_ | = | substr(h1line_,56,lcomment_) |
| |
| group_ | = | asc(substr(h1line_,111,1)) |
| |
| lpath_ | = | asc( substr(h1line_,117,1) ) |
| path_ | = | substr(h1line_,118,lpath_) |
| |
| /// |
| |
| do while not eof() |
| |
| | readrecord() |
| |
| | extract() |
| |
| | suche path in dlimp:physicalpath |
| | get ownid |
| |
| | save in dlimp2 |
| | *AID |
| | areatag |
| | areadesc |
| | physicalpath |
| | grouptag |
| | cid |
| enddo |
- TIC Import
==========
-------------------------------------------------------------------------------------
Created by HTick, written by Gabriel Plutzar
File net2411.upd
Area TEST
Areadesc Pointlist-Updates for Net 2:2411
Desc Net 2:2411 Pointlist Update
Replaces net2411.upd
From 2:2411/525
To 2:244/1120
Origin 2:2411/525
Size 2445
Crc FA32DE35
Path 2:2411/525 1138291501 Thu Jan 26 16:05:01 2006 UTC HTick/lnx 1.3.0-cur 06-02-03
Seenby 2:244/1120
Seenby 2:2411/525
Pw 12345678
-------------------------------------------------------------------------------------
read tic line by line
$tcount = 0
do while not eof
do case
case 'Area'
query dlimp2 for areatag, get cid, physicalpath
query dlimp for ownid get l1, l2 erweitern um FBA?
$cid Noe, OWNID ist produktiv
$path FBA nur in Step 2
$tcount = $tcount + 1 phpnuke admin-console
case 'File' Bei der Definition
$filename
$tcount = $tcount + 2
case 'Desc'
$description
$tcount = $tcount + 4
case 'Size'
$size
$tcount = $tcount + 8
endcase
enddo
version = version(filename,description)
submitter = DLTIC v1.00
if $tcount = 15 and (OWNID > 0 or FBA > 0)
existiert file bereits?!?
update _downloads with New*LID, cid, title (file+desc), url?, desc, date, name, email,
submitter, filesize, version, homepage
update _dlmgmt with New*LNO, lid, cid, l1, l2, fe
endif
Weiterhin: Update FILES.BBS size / crc, Update Num. Files in Area, Update Sum FSize in Area
in _DLIMP
- *** Gibt es eine Solution _OHNE_ existierende DLIMP DB ... ?
... wo DLIMP durch die Allfix Gruppen und Area Konfiguration neu
aufgebaut wird? => Nein.
Die DOWNLOADS Untergruppierung kann durch eine Allfix Groups Definition
nachgebildet werden. Alle Areas die der Allfix Gruppe zugeordnet sind
können in DOWNLOADS abgebildet werden.
Problematisch wird es erst bei einem Verzeichnis Sharing mehrerer Allfix Areas
(i.e. Areas: NODEDIFA, NODEDIFZ, POINT4D Einspeicherung auf Verzeichnis: Q:\SERVICE).
Aus der Filebase Implementation sind Verzeichnisse Unique in der DLIMP DB vorliegend.
Ein Verzeichnis Sharing aus Allfix Areas wäre durch eine weitere Tabelle, die
eine n:1 Zuordnung von AFIX Areas zu FileBase Verzeichnissen enthält möglich.
Daraus ergibt sich folgendes:
Eine AFIX Umsetzung erzeugt eine zusätzliche Tabelle zu der bereits existierenden
DLIMP (FileBase) Tabelle, in der die Allfix Konfiguration in die FileBase
'übersetzt' wird. Die DLIMP Konfiguration muss bereits vor einer AFIX Umsetzung
existieren. Eine Standalone Version des AFIX Pakets kann es aufgrund der
zuvor genannten Vorraussetzungen nicht geben.
Beim Übertragen der AFIX Konfiguration in die DLIMP Umgebung muss eine
Prüfung des DLIMP Bestands durchgeführt werden. Entweder in der Form,
dass AFIX Areas nur dann 'aktiviert' werden, wenn ein DLIMP Verzeichnis
vorhanden ist, oder wenn der DLIMP Datenbestand 'vollständig' ist.
Einige Fragen die die weitere Vorgehensweise beeinflussen könnten bzw. eine
Erweiterung des Systems nach sich ziehen könnten:
- Wann ist ein DLIMP Datenbestand vollständig?
- Was ist mit inaktiven AFIX Areas deren Pfade in DLIMP nicht existieren?
- Was ist mit i.e. administrativen AFIX Areas, die nicht nach DLIMP überführt werden sollen?
Aus Frage 1. ergibt sich schon fast zwangsläufig eine Report Lösung anzustreben.
Erst einmal versuchen alle AFIX Areas zu übertragen. Wenn kein passendes Verzeichnis
in DLIMP gefunden wird Generierung eines Reports:
Area XYZ, Path ABC, Path not found in DLIMP
Area wird zwar in die zusätzliche Tabelle übernommen, aber auf Status 'inaktiv' gesetzt,
so dass bei einem Import die Area übersprungen wird.
Mit dieser Lösung wäre auch bereits Frage 2 beantwortet.
Frage 3 ist dagegen vielschichtiger. Was wenn der Pfad bereits aus der Filebase
nach DLIMP übertragen wurde, die Area aber nicht für die aktive DOWNLOADS Sections
aktiviert wurde?
Aktive DOWNLOADS Area definiert sich durch OWNID > 0 or FBA > 0.
Wenn OWNOD = 0 and FBA = 0 dann ist per Definition die Area zwar in DLIMP aufgeführt
aber inaktiv.
$block_act = 0;
if ($dlaoid > 0 OR $dlafba >0) {
//if ($dlapid == 0) {
if ($dlaipa > 0 ) {
if ($dlaipa == 1) {
// requested DEACTIVATE
$active = ""._REQINACTIVE."";
} else {
$active = _ACTIVE;
$block_act = 1;
}
} else {
$active = _ACTIVE;
$block_act = 1;
}
} else {
// augenblicklicher Status INACTIVE, REQ Activate
// or REQ Inactivate, option aktivieren,
// dektivieren
Beim Auslesen von DLIMP muss dies also für den späteren Import Prozess berücksichtigt werden.
[4.2.06]
Nachdem das Einlesen der Allfix Groups- und FileArea Konfiguration abgeschlossen ist, und nun die
Bearbeitung in der PHP-Nuke Admin Console ansteht, habe ich zunächst einmal nur einen Ansichtsmodus
erstellt.
Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config:
Sofern eine bereits existierende AreaID in DOWNLOADS existiert, kann der Status der AFIX Konfiguration
geändert werden (-> Active/Inactive).
Mit
Details können erweiterte Informationen zu der zugeordneten DOWNLOADS Area und der
entsprechenden AFIX Area abgerufen werden:
Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config, AFIX Config Details:
Existiert zu einer Allfix Area keine Entsprechung in DOWNLOADS (keine Übereinstimmung des Pfads), könnte
aus den Allfix Konfigurationsinformationen recht einfach eine neue DOWNLOADS Area erstellt werden.
Das ist besonders dann Interessant wenn neue FileEchoes automatisch in Allfix erstellt wurden.
Weiter oben habe ich zwar eine automatische Übernahme der
Allfix-Konfiguration
nach
PHP-Nuke Downloads ausgeschlossen (siehe auch
"Die DLIMP Konfiguration muss bereits vor einer AFIX Umsetzung existieren"), das gilt aber nur für die Initialisierung, Erstellung einer Basiskonfiguration.
Existiert dagegen bereits ein DLIMP Datenbestand und liegen bereits genügend
Allfix Informationen vor, können mit der Sammlung all dieser Informationen
die fehlenden Informationen bei der Erstellung einer neuen Area unter DLIMP herangezogen
werden. Die Zuordnung der übergeordneten Kategorie und die Aktivierung der Area
unter
PHP-Nuke Downloads unterliegt aber weiterhin der Entscheidung
des Sysops, der hier interaktiv tätig werden muss.
Zwar wird, die übergeordneten Kategorie betreffend eine Voranalyse laufen gelassen
(wie wurden andere vergleichsweise konfigurierten Areas zugeordnet?), die letztendliche
Zuordnung muss aber immer noch der Sysop treffen.
Screenshot DLIMP PHP-Nuke Admin Console v1.10 incl. AFIX Config, AFIX Config Details, Erstelle neue DOWNLOADS Area:
[5.2.06]
Erstellen einer neuen FileArea mittels AFIX Konfigurations Daten ist nun implementiert. Die neue FileArea
wird in Downloads nun automatisch aktiviert (entgegen der DLIMP Konfiguration Speichern Methode).
Änderungen die in der DLIMP Umgebung getätigt wurden, werden dabei allerdings nicht
berücksichtigt. Allerdings gehen auch keine Informationen verloren (i.e. Request Activate Area).
Jeddoch muss um diese Änderungen auch zu übernehmen noch zusätzlich die Funktion
Aktiviere DLIMP Konfiguration aufgerufen werden (siehe auch
DLIMP Sonderfunktionen).
Änderung der Allfix Area Beschreibung:
Zur Änderung der Area Beschreibung muss zunächst mit der AFIX Konfiguration - Details - Funktion:
Neue FileBase Area anlegen die neue Area Konfiguration in Downloads aktiviert werden.
Anschliessend kann unter
DLIMP Konfiguration eine Änderung an der Area Konfiguration
vorgenommen werden. U.a. Änderung der Area Beschreibung
(siehe auch
DLIMP Area überarbeiten).
This behavior is by design.
Problem: In der Testumgebung sind beim Speichern der DLIMP Konfiguration die
BASEPATH und
HOMEPAGE
Definitionen verschwunden.
Die Basepath und Homepage Konfiguration kann nun noch an einer Stelle erfolgen. In der DLIMP Übersicht
gibt es am unteren Rand die Einstellmöglichkeit für diese beiden Parameter. Die Speicherung
dieser beiden Parameter erfolgt nun noch mit einer Funktion. Beim Speichern der Angaben erfolgt
nun eine Validitätsprüfung (siehe auch
DLIMP Sonderfunktionen).
Status: Fixed.
[16.2.06] Im Zusammenhang der Vorbereitungen für den Ticker Import bin ich auf die Problematik
gestossen entweder die Angaben zum Tickern (wo finde ich die Tic Files, von welcher AKA
und mit welchem Password kommen die Tics, an welche Addresse werden die geschickt?)
manuell im Rahmen der DLIMP2 Überarbeitung mit einzugeben, oder aber im Areas.Fix Import
Schritt aus der Allfix Setup.Fix Konfiguration auszulesen, so dass nur noch die Angabe
der eigenen Downlink AKA fehlt, für den das Päckchen vom Uplink
zur Verfügung gestellt wird. Sprich: In Step 2, PHP-Nuke Admin Console sollte nur
noch die AKA einzutragen sein, die für den PHP-Nuke-Ticker benutzt werden soll. Alle
anderen Angaben wie Tic Filepath, Maileroutbound, Downlink Konfiguration sollte aus
dem Allfix Setup.Fix ausgelesen werden.
Da in der bisherigen Analyse die Analyse des Setup.Fix nicht vorkam, bin ich nun seit
3 Tagen daran zu versuchen die Setup.Fix Struktur zu entschlüsseln. Trotz der
Struktur Informationen gestaltet sich das äusserst schwierig, da eine komplette
Umsetzung aus der Pascal Notation zu absoluten File Positionen stattfinden muss
um die Setup.Fix mit PHP einlesen und verarbeiten zu können.
Da sämtliche Daten sequentiell Parameter für Parameter aneinandergeklatscht sind,
die Datentypen aber ständig wechseln, bin ich immer wieder auf Fixpunkte angewiesen,
von Einträgen die ich identifizieren konnte. Dazu gehören vor allem eindeutige
Textpassagen. Noch bin ich auf so Merkwürdigkeiten gestossen, dass ein Datentyp LongInt
68 bytes ausmacht (!!!). Entweder habe ich mich irgendwo verzählt, die Angaben in
der Definition sind nicht völlig korrekt oder aber es sind tatsächlich 68 bytes ....
Bislang habe ich ca. 15K der 18K Daten entschlüsselt. Aber es zieht sich noch ein wenig hin.
Weiterhin ergibt sich ein weiterer Zwischenschritt im Gesamtprojekt (Import Allfix Setup.Fix).
[19.2.06] Nachdem das Allfix Setup.Fix nun entschlüsselt ist, kann ich mir nun Gedanken machen
welcher der Informationen ich in DLTIC benötige.
-
Im wesentlichen geht es einmal um den Binkley Outbound, in dem die Flow Files zu finden
sind, die den Link zum vertic'tem File und dem dazugehörigen Tic File liefert.
-
Der TicPath wird an sich nicht benötigt, da die Tic File Informationen aus den
Flow Files ausgelesen werden.
-
Für die DLTIC Konfiguration wäre die Überprüfung der Allfix Version
eventuell von Bedeutung, wenn sich mit einer Revisionsänderung auch eine Strukturveränderung
ergibt.
-
Falls auch noch die Nodemanager Konfiguration ausgewertet werden sollte, wird auf alle Fälle
der Parameter FEnumSystems benötigt, um die Struktur Dimension des Konfigurationsfiles
ermitteln zu können.
-
Für das Auslesen der Tic Files wird auf alle Fälle zur Überprüfung
des Uplinks die Liste der AKAs (NetAddress) benötigt, von denen eine
Weiterverarbeitung erfolgen soll.
-
Um auch noch an das Tic Password zu gelangen, müsste sofern der Eintrag im Allfix Nodemanager
bereits erfolgt ist auch noch das NodeFile.Fix ausgelesen werden. Da ich hierbei nicht mit Sicherheit
von ausgehen kann, muss ich die Annahme treffen, das die Information nicht vorliegt (daher bislang
noch nicht vorgesehen). Demzufolge muss die Eingabe der AKA und des Tic-Passwords für die DLIMP
Konfiguration manuell erfolgen.
Hier nun die Parameter im Einzelnen und die jeweiligen absoluten Fixpositionen der Informationen
zur Basis 1 (1 = 1tes Byte aus der Datei Setup.Fix)
In der PHP String Verarbeitung müsste zu den angegebenen Fix-Positionen immer -1 abgezogen werden.
Eine Auswahl der benötigten SETUP.FIX Content Informationen
Allfix v5.13 build 4
Basis 1
[position,length]
len content
-------- ---------------------------------------
TicPath : Q:\PT13\ 490,1 491,60
OutBound : H:\BINK\OUT\OUT\ 917,1 918,60
Sysop : Ulrich Schroeter 1100,1 1101,30
AFIXversion : 5.13 ptr1: 9442,1 + '.' + ptr2: 9443,1
AFIXbuild : 4 9444,1
FEnumSystems: 255 15119,1
Offset: [17105] [0..40]
NetAddress : 2:244/1120.0 zone ptr1: offset,1 ptr2: offset+1,1
NetAddress : 2:244/1120.0 net ptr3: offset+2,1 ptr4: offset+3,1
NetAddress : 2:244/1120.0 node ptr5: offset+4,1 ptr6: offset+5,1
NetAddress : 2:244/1120.0 pnt ptr7: offset+6,1 ptr8: offset+7,1
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0 offset = offset + 8
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0 ( ptrB * 256 ) + ptrA
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 2:244/1120.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
NetAddress : 0:0/0.0
Wie schon weiter oben beschrieben, werden einige zusätzliche Informationen benötigt,
die so nicht aus der Allfix Setup.Fix Konfiguration auszulesen sind und daher in der DLTIC
Konfiguration manuell eingegeben werden müssen:
AKA bzw. NetAddress (Point-AKA)
Tic-Password (zum Uplink)
Falls die Tic und Files in ein Spool Verzeichnis geschoben werden, müsste das aus Allfix
übernommene Outbound Verzeichnis (Binkley Root Outbound Verzeichnis für die primäre
Zone) überschreibbar sein. Beim Speichern der DLTIC Konfiguration muss darauf geprüft
werden, ob das übernommene Verzeichnis das Binkley Outbound Verzeichnis oder ein anderes
Verzeichnis ist, ob eine Umsetzung in der Directory Struktur erfolgen muss oder nicht
(Spoolverzeichnis bleibt Flat, Binkley Outbound verzweigt in Unterverzeichnisse bei
Point Konfigurationen (i.e. ..\00f40460.pnt\00000237.hlo).
Die Liste der NetAddresses kann auf Unique komprimiert werden, da nur die Liste der
unterschiedlichen Addressen benötigt wird von denen Files geschickt werden können.
Die Addressen 0:0/0.0 sind dabei zu ignorieren (NUL, N/A).
Nachdem nun die Allfix Uplink Parameter in DLIMPCFG eingelesen sind, hier nun der erste Screenshot
von der zusätzlichen Uplink Konfigurations Seite:
Screenshot DLIMP PHP-Nuke Admin Console v1.10, AFIX Uplink Config:
Von der Ablauflogik sind nun nacheinander 3 Submenüs verschachtelt.
| Menü 1: DLIMP Filebase Konfiguration |  |
| Menü 2: DLIMP Allfix Konfiguration |  |
| Menü 3: DLIMP Allfix Uplink Konfiguration |  |
wobei solange keine Allfix Uplink Informationen gespeichert wurden, das Menü 2 nicht aufgerufen
werden kann und immer wieder in die Allfix Uplink Konfiguration verzweigt.
Hier muss mindestens die eigene AKA definiert werden, damit die weitere Konfiguration im Menü 2
getätigt werden kann.
[21.2.06] Bei der weiteren Analyse der Allfix Konfigurationsparameter bin ich im Allfix Setup über das
Hold Directory das im Nodesmanager eingetragen werden kann gestolpert.
Das bietet Grund für unterschiedliche Verfahrensweisen bei der DLTIC Verarbeitung.
1. Benutze den regulären Binkley Outbound mit Flow-Files, aus denen die zu vertickenden Files
auszulesen sind.
2. Benutze das Allfix
Hold Directory für den DLIMP Downlink.
In beiden Fällen sind beim DLTIC unterschiedliche Vorgehensweisen vonnöten.
Im ersten Fall muss in der Binkley Outbound Struktur nach dem entsprechenden Flow-File gesucht werden
und abgearbeitet werden. Ebenso muss ein Handling des Flow-Files selbst erfolgen.
Im zweiten Fall muss nur das
Hold Directory nach TIC Files durchsucht werden. Die TIC Files
ausgelesen werden und das zugehörige vertic'te File nach PHP-Nuke Downloads importiert werden.
Da hier zwei gänzlich unterschiedliche Verfahrensweisen zur Anwendung kommen, muss in der DLTIC
Konfiguration dem Rechnung getragen werden. Nun besteht die Möglichkeit, diese Informationen
automatisch aus der Nodesmanager Konfiguration von Allfix auszulesen oder aber diese Informationen
händisch in die DLTIC Konfiguration einzutragen. Ersteres setzt vorraus, das die DLTIC Downlink
Informationen bereits in Allfix eingetragen sind. Zweiteres bedeutet doppelte Arbeit und eine zusätzliche
Fehlerquelle. Nur beim Erstaufruf der DLTIC Konfiguration ist die Downlinks-AKA noch unbekannt. Die
Verknüpfung findet erst im Zuge der DLTIC Konfiguration statt und erst dann kann überprüft
werden ob dazugehörige Informationen im Allfix Nodesmanager vorliegen. Fehlen die Angaben ist
die DLTIC Konfiguration
unvollständig. Sind die Angaben vorhanden, ist die DLTIC Konfiguration
vollständig. Hierdurch können zweifelsohne Inkosistenzen entstehen.
Dem DLTIC kann es egal sein, ob bereits ein Eintrag in Allfix vorgenommen wurde oder nicht. Solange im Allfix
Nodesmanager noch kein Eintrag für den DLTIC Downlink existiert, solange können auch noch keine
Files vertic't werden. Erst wenn ein Eintrag im Allfix Nodesmanager für den DLTIC Downlink durchgeführt
wurde, wird die Sache ernst. Beim DLTIC Import selbst kann aber eine Prüfung eingebaut werden, ob die
DLTIC und Allfix Nodesmanager Konfiguration konsistent sind. Wenn Differenzen zwischen der DLTIC und der Allfix
Downlinks Konfiguration zu finden sind (alternate Hold Directory oder Default Binkley Outbound), kann
eine erneute DLTIC Konfiguration getriggert werden.
Eine Auswahl der benötigten NODEFILE.FIX Content Informationen
Allfix v5.13 build 4, Nodesmanager NODEFILE.FIX
Basis 1
Record Length: 388 bytes
[position,length]
len content
-------- ---------------------------------------
NodeMGRrec : 2:244/1120.888 1,8 ptrA ptrB
---------------- ----------------
zone ptr1: offset,1 ptr2: offset+1,1
net ptr3: offset+2,1 ptr4: offset+3,1
node ptr5: offset+4,1 ptr6: offset+5,1
pnt ptr7: offset+6,1 ptr8: offset+7,1
jeweils ( ptrB * 256 ) + ptrA
Sysop : DLIMP 9,1 10,35
Password : *************** 45,1 46,20
Inactive : FALSE 99,1
TicFile : Normal 105,1 {None,Normal,Advanced} Basis 0
UseAka : 0 106,1
Archiver : ZIP 109,1 {ARC,ARJ,LHA,PAK,ZIP,SQZ,RAR,J,9,10} Basis 1
Forward : TRUE 110,1
MgrPassword : *************** 112,1 113,20
PackMode : No packing 134,1 {No packing,Pack TIC files,Pack ALL files,TIC + file}
Basis 0
SystemPath : H:\BINK\OUT\DLIMP\ 204,1 205,60
PktPassword : ******** 270,1 271,8
[23.2.06] Ich bin jetzt soweit gediehen, dass bei der DLTIC Uplink Konfiguration die notwendigen
Allfix Informationen ausgelesen werden und mit zur Anzeige gebracht werden, sofern Downlink
Informationen vorliegen. Schlussendlich muss an sich nur die Downlink AKA eingetragen werden.
Alle weiteren Informationen holt sich das System aus den Informationen aus dem Import Stufe 1
(Allfix Rootpath, Outbound Path, Uplink-Sysop, usw.) und aus der Überprüfung
der Allfix Nodemanager Konfiguration (TIC Password, Hold Directory, TIC Typ, usw.).
Solange in der Allfix Nodemanager Konfiguration noch keine Downlink Informationen zu finden
sind, solange bleibt auch die DLTIC Uplink Konfiguration unvollständig.
Screenshot DLIMP PHP-Nuke Admin Console v1.10, AFIX Uplink Config v2:
Zur Installation und Einrichtung von DLIMP / DLTIC ergibt sich nun folgende Vorgehensweise:
- Installation und Konfiguration Gesamt DLIMP Filebase/Downloads System
- Allfix Setup Aufruf, Eintrag der DLTIC Downlink Informationen (AKA, Sysop, Passwort)
Entweder als Standard Downlink Eintrag (mit regulärem Binkley Outbound) oder
mit HoldDir Spoolpath
- Konfiguration DLTIC\includes\constants.php Eintrag Allfix Rootpath
- DLTIC1.php Aufruf zum Transfer der Groups und Areas von Allfix nach DLIMP
- Aufruf Admin Console, DLTIC Konfiguration
- Eingabe der zu verwendenden Downlink AKA
- Speichern
- Konfiguration DLTIC Areas
- Speichern
- Fortlaufender Aufruf des Tickers DLTIC3.php zum Importieren von TIC Files
[25.2.06]
Beim Test der TIC Import Funktion wollte ich die 3 Testareas, die im Allfix bereits konfiguriert
waren in den PHP-Nuke Downloads Bereich aufnehmen. Hierzu musste ich eine der 3 Testareas zunächst
neu hinzufügen (siehe auch
Add Area). Hierbei gab es nun eine Schwierigkeit.
Da alle 3 TIC Areas in ein und dasselbe Verzeichnis verweisen, wurde zwar eins der TIC Areas in
PHP-Nuke Downloads aktiviert, aber die beiden anderen TIC Areas liessen sich, obwohl nun
das Verzeichnis für Downloads existierte, nicht aktivieren.
Nachdem ich den Admin Consolen Script um eine Überprüfung beim Hinzufügen neuer
Areas erweitert habe, indem auch alle anderen Areas die dieses Verzeichnis benutzen für die
Aktivierung in PHP-Nuke Downloads freigeschaltet werden, stehen nun auch alle weiteren TIC Areas
in der Admin Console für die Aktivierung zur Verfügung.
Status: fixed.
[25.2.06]
BugTrack rep060225.001
Nach dem Hinzufügen neuer Areas im Zusammenhang mit TIC Areas kann eine Dateninkosistenz auftreten,
hervorgerufen durch die asynchrone Verarbeitung durch den Synchronisationsprozess (DLIMP) und
einer vorzeitigen Bearbeitung durch DLTIC.
Wenn in der Admin Console in der AFIX Areas Konfiguration eine Area hinzugefügt wird, in der
bereits etliche Files in der realen Filebase existieren, werden beim DLTIC Import nur die
neuen Files nach PHP-Nuke Downloads importiert. Alle älteren Files bleiben aussen vor.
Da auch ein Update der Files.Bbs Informationen erfolgt kann somit bei einem späteren
DLIMP Synchronisationslauf diese Area nicht mehr mit dem Status
geändert erkannt werden.
Ein automatisches Triggern einer DLIMP Synchronisation ist nicht so ohne weiteres möglich, da
die Steuermechanismen (Semaphore File?) für die Synchronisation auf jedem System unterschiedlich
sein können. Hierzu müsste dann zusätzlich in der DLIMP Konfiguration das
zu verwendende Semaphore File definiert werden. Da auf manchen Systemen die Synchronisation aber
auch ohne Semaphore File auskommen könnte, ergibt sich hieraus nun ein Dilemna.
Generell gilt: nach Anlegen einer neuen Area in der AFIX Areakonfiguration muss eine DLIMP
Synchronisation angestossen werden, um die neue Area komplett nach PHP-Nuke Downloads zu importieren.
Eine Möglichkeit würde jetzt noch bestehen: die Synchronisation einer Area in
der DLIMP/DLTIC Admin Konsole nach dem Hinzufügen einer neuen Area nachzubilden.
[13.3.06]
Beim DLTIC Import werden nun beim Auswerten des TIC Files, nachdem der AreaTag festgestellt wurde,
zusätzlich die Sync Informationen für DLIMP aus der DB ausgelesen und geprüft. Wird ein TIC
zu einer bislang inaktiven Area verarbeitet, wird ein automatischer DLIMP UpdateArea() Aufruf für
diese Area gezündet und abgearbeitet. Anschliessend wird das TIC zusätzlich in die Area
mit aufgenommen. In diesem Zusammenhang habe ich sämtliche von DLIMP und DLTIC gemeinsam benutzte
Funktionen in ein Include File
includes\func_dli.php ausgelagert.
Status: fixed
[26.2.06]
Werden für den DLTIC Downlink TIC Files von inaktiven TIC Areas ins Spoolverzeichnis geschoben,
behandelt DLTIC die Files wie folgt:
TIC Files werden in .BAD umbenannt. Die dazugehörigen vertickten Files verbleiben ebenfalls
wie die BAD Files im Spoolverzeichnis.
Status: added
[26.2.06]
DLTIC über Downlink HoldDir fertig gestellt. Noch offen: Verarbeitung aus Binkley Outbound
heraus mit Flowfile Handling.
Status: info only
[28.2.06]
DLTIC über Uplink Binkley Outbound Flowfiles fertig gestellt.
Flowfile Handling, Handling der TIC Files.
Status: info only
[28.2.06]
Problem Report: Im Unterschied zur FileBase Synchronisation wurden beim DLTIC Import Beschreibungen nur in
Kurzform übernommen.
Beim Auswerten der TIC Files wird nun auch das Feld
Ldesc ausgelesen. Sollte im TIC ein Feld
Ldesc
vorhanden sein, wird statt der Kurzform
Desc die Langfassung der Beschreibung aus
Ldesc
importiert. In der AFIX Konfiguration erscheint nun beim entsprechenden TIC Typ nun zusätzlich
ein Hinweis besser in den
Advanced TIC file mode umzuschalten falls dieser auf
None
oder
Normal gesetzt ist. Dies kann aber nur im ASETUP selbst umgeschaltet werden.
Status: fixed
[28.2.06]
Problem Report: Beim Wechsel von ASETUP Downlink HoldDir auf Binkley Outbound lieferte
die DLIMP2.PHP Console im AFIX Konfigurationsmenü falsche Ergebnisse.
Zunächst blieb das HoldDir auf dem eingestelltem alternativem DLIMP Spoolpath.
Nachdem ich das Feld
DLTIC Alternatetives Spool Verzeichnis und Datei(en) auf den Default
Wert von
AFIX Uplink Binkley Primärer Zonen Outbound gesetzt habe, wurde der berechnete
Spoolpath korrekt angezeigt und in die Konfiguration übernommen.
Fixed. Jetzt besteht aber die Möglichkeit, dass vergessen wird die neue Konfiguration zu speichern.
Zwar wird der Path (Files) laut aktueller ASETUP Einstellung angezeigt. Das heisst aber nicht, dass auch
die aktuellen Werte in der DLTIC Konfiguration gespeichert sind.
In Erweiterung erscheint nun neben der Anzeige von
DLTIC Alternatives Spool Verzeichnis und Datei(en)
solange ein Hinweis, bis die neue Konfiguration gespeichert wurde.
Status: fixed
[7.3.06]
BugTrack rep060307.002
Versionsnummern Analyse macht nicht das was sie soll. Generelle Überarbeitung der Funktion ....
[12.3.06] Version() v2 arbeitet nun mit verschiedenen Mustererkennungen. i.e. v#.#, v.#.#, version #, usw.
Status: fixed
