Macola's Use of Active Directory 1

[Jandr]

I am looking for some background on Macola's (ver. 705.103.f) use of the Win2000 Active Directory. In general, does it play nicely?

I want to build a customor extranet that can share the usernames and passwords that are already stored for a customer account within Macola.

Is that information even placed in AD? or does Macola handle that in a proprietary way?

Is the answer different if the user is Btrieve vs SQL?

Basically, I am hopting Macola uses objects within the Win2000 default "\Users" OU to store customer info? Is that true?

(This level of information does not appear on the Macola website...apparently they only share that level of detail with re-sellers, which I am not.)

 

[vbajock]

Macola 7.x itself does not use AD in any way. ODBC connections set up to access Macola data, however, would be dependent on the security set up of the database engine (Btrieve/SQL Server) itself. On SQL Server 2000/ Win 2000 Server set ups you could probably find hooks into AD. Myself, in SQL2000/2000 enviros I would access Sql server itself to manage any data security issues and not mess with AD. In Btrieve enviros any ODBC security has to be programmed into the app, since by default the Pervasive ODBC drivers allow total access to all the data, which sucks.

 

[Jandr]

Thank you very much. This was as I feared.

When you refer to accessing the SQL server itself..I will have full admin access to all the tables, but having never yet seen a Macola data structure for SQL...is there a USERS table (or something easily found), or is it buried deeply in some proprietary mess?

Alternately, is there an Authentication API that Macola has that will let me authenticate its users that it stores in SQL or Btrieve?

 

[vbajock]

Your asking about an area that is a little too broad for a chat room. You should get an IT consultant or go crack some books. Personally, I wouldn't get involved in a project whose aim was to put an accounting systems' users and passwords out on the Internet without 1) an explanation of why it is being done or 2) without getting paid for it.
Good luck with your project.

 

[zedsded]

Im currently using WIN2000 and PSQL (still under BTRIEVE engine, dont be mislead), and I am still in the process of making my AD work ideally.PSQL and MACOLA doesn't have an authentication tool (as far as I know). Even installation instructions from Macola says to give the user full rights to the database(*defeats the purpose). I am actually stuck in this setup right now. And this is only in my LAN w/o external user.
GOOD LUCK!

 

[dgillz]

I have two question, what is AD, and why are you attempting to put user passwords on an intranet?

I even have a crystal report that I occassionally sell that displays the passwords of the users, but like vbajock I do not do this lightly, I make sure that there is a darn good reason for this and that I am dealing with someone in a position of authority in the company.

On the rights issue, the users musy have full rights to the Macola database directory, by design. After all, if you did not have write access to the database how could you add a new customer, a new order, etc.?

Even printing and posting an invoice, and in some cases performing an inquiry (for example a complex drill down inquiry that causes a work file to be created), writes to the database.

You can stop an individual from adding a new customer or performing some process in Macola and this is handled with Macola's visual menu builder. You can, module by module, or menu option by menu option, deny the person the access to that menu option within Macola.

If you had a user with Macola menu options limited to simple inquiries, and you gave that person read only rights to the Macola database, I believe it would work, but I have never put that to the test. I strongly advise you go with the recommendations and give the users full rights to the Macola root directory.

There are some holes with this approach, but if you have some specific concerns of what they might do in this setup, post them here and we can explore it more in depth.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

dgilsdorf@trianglepartners.com

 

[vbajock]

AD stands for Active Directory, which is new in Windows 2000 on up. This is a hugely overly simplified explanantion:
AD is meant to be a central repository of all property settings and attributes for all resources on a given network. The central user database for a domain is stored here, and many new applications, notably SQL 2000 and Exchange 2000, integrate with the user database rather than maintain a separate user database for each application.

 

[dlreeves]

We have been using AD in both an Intranet and Extranet environment for a couple of clients. I think what needs to be determined is what you are wanting them to view. Most often it is inventory information or order information. This being the case, if you are running SQL side of Macola, not P.SQL, you could use other tools to post this information in a warehouse environment that would insure data security and not let folks poke holes in Macola itself. Then you only have to worry about firewall authentication. What is the application you are trying to apply.
Don Reeves
SCSI Business Solutions, LLC

http://www.scsi-usa.com

 

[Jandr]

Thanks for the interest.
The application can best be descibed as a dealer extranet.
The customer is a manufacturer whose product is sold via dealers. Each dealer would be able to log in to see product information, training manuals, repair and warranty info our of our customized Content Management System environment. The macola tie in would be a phase two step to also offer them custom quotes, access to pricing that is unique for each dealer and 'real-time'inventory info.
Macola web views is supposed to do this..but not in the way that fits in with their business model.
We have a great CMS that uses AD not just to hold users, but to hold critical web page layout info. In that fashion it is practically un-hackable (well, you know what I mean . I am trying to find a way to deliver on phase one, and then allow a single sign on so we can retrieve macola data and present it to customers through our CMS portal.
Hence, the desire for Macola to share our AD users...or find a reasonable way to synch those or pass certifications so we can query inventory and pricing from macola as if we were the customer, using their id and associated rights.

One posting above misunderstood. I do not have any intention of posting usernames and passwords to the internet...
Sounds like you prefer to store data offline, so the internet based queries go to a copy of the macola data. This is one option..but real time is preferred. I do not see real time as a security risk if my CMS is making the query and presenting the data.

 

[vbajock]

Are you wanting to execute programs within Macola and return the resulting reports to the user, or are you wanting to return Macola data to your application so that it can be manipulated within your application and then presented to the user?

 

[Jandr]

We are not far enough along to definitively answer that very important question...but I was presuming that we would execute programs within Macola and return the resulting reports to the user through our interface.

 

[vbajock]

I doubt if Macola could execute programs and deliver results over the web, at least not in verision 7.x. Poster dgillz would know more about that than I would. dlreeves' post above is the approach most commonly taken to distribute Macola data over the web, although he is in error about P-SQL. These days, it doesn't matter what the database engine is, with a combination of ADO or ADO.NET, XML, ASP, Vbscript, etc, you can build any warehouse repository for web use.

 

[dgillz]

I would check out a Macola reseller in Tampa called Global Software Connections. They have their own Macola web based product which works with both Pervasive and MS SQL, and it can do a lot of things that Macola's Weborders cannot do.

Another possibility is publishing crystal reports to the website. It is also very expensive, just like Weborders.

Let me know if I can be of any help. Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

dgilsdorf@trianglepartners.com

 

[MacolaHelp]

GSC's MacWeb product is definitely more powerful than WebOrders/Webviews. A client of mine runs it & it very effectively allows dealers access to info they need from Macola. Let me know if I can help direct you to people who can answer your specific questions. As part of our project, we not only allow web based order entry, but Crystal reports are also published to the web for our customers.

 

[dgillz]

MacolaHelp,

If you are publishing crystal reports to a website, make sure you are not in violation of the Crystal Broadcast License.

This is discussedin detail in the Crystal reports forums. This can cost you and/or your clients huge $$$$.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

dgilsdorf@trianglepartners.com

 

[Jandr]

Thank you very much...that is an issue I did not even think of...I did not know Crystal had a "Broadcast license"

Thank you all for your postings, it has really helped me to get the project on track -

 

[MacolaHelp]

jandr:

MacWeb uses an asp to connect to the Macola DB from the IIS server running the web based order entry front end. It's pretty fool proof in the security arena & works with either p.sql or mssql for the macola db. They are also very close to a "release candidate" b2c solution to accompany their b2b & vendor management pieces. If you can use all/part of their code to get you where you need for your client, you'll save yourself a lot of development time & your client a lot of money. FYI: my client is using Crystal Enterprise (a serious financial hit, BTW) to publish reports to the web for the users to access on demand. It works great for them & they were willing to cough up the dough to do it. In fact, I think it may have cost more than MacWeb. Talk to Hugh @ GSC for further clarification on their offering if you want to explore more.