Hartmut Wöhrle wrote:
I think Apache DS may make a great meta-directory engine, as you have described. It's probably much easier to extend it to talk to different types of data stores (think JDBC) than to extend Fedora DS using C plug-ins.Hello everybody.I'd like to start a discussion about extending the replication possibilities of FDS, because from my problem with NT synchronization, I got some ideas.... ;)What I learned from the Winsync tool is the following:FDS connects via LDAP to the JAVA based ApacheDS on the Windows PDC. So in fact it is a connection between two LDAP directories. Next it connects to the NT database via an API service-to-service connect and gets the needed data to synchronize users to the FDS.So why not extending this way of getting data from a non-LDAP system to the FDS, for example a database. The technique I have in mind would go the following way (same as Winsync):FDS --> ApacheDS --> connector to the service and the data back.So the connection FDS to ApacheDS is standart ldap/ldaps. What's needed is a plug for the connector. Then the connector could be programmed in any way:- script to read out a perl script and change values to LDAP schemas - call a programm with parameters (database SELECT, or cyrusadm with params) - something like an API or socket connectIn my case I'm thinking about a connection with a SAP HR database, which exports the data in an IDOC format (flat file). So first I had in mind to scp this file to the FDS server, rewrite it in a LDIF format and read it in by ldapmodify. But using the way above would look the following way:A connector rewrites the IDOC format to LDIF and hands it over to the ApacheDS, which sends it (like the Winsync) to the FDS. The advantage from this method is the ldaps connection that I can use for transmit, instead of scp or sftp. The other advantage is, that the ApacheDS is based on JAVA, so could easier be ported to other systems. Then the only OS-dependent part is the connector. And this one could be programmed for every needed case.What do you think about this - or is there any need for something like this?
For the specific case you described though, we did this at Netscape several years ago with our Peoplesoft HR database, using PerLDAP. We would take a dump of the database, parse it with perl, and use perldap to send the LDAP operations to the DS. No need for an intermediate LDIF file. You may be able to do the same with an Apache DS solution, if it can connect directly to SAP using JDBC or something like that.
CU Hartmut
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
