• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 285
  • Last Modified:

Need some tips on setting up this distributed solution..??

I'll try and make this a quick intro.

I have a PHP class library that I wrote that allows PHP developers to integrate PayPal API's into their solutions very easily.  It includes every possible call that PayPal offers and makes them all very simple to work with.

With FileMaker, I'm using the Scodigo PHP SmartPill plugin to give me the power of PHP within FileMaker, which is great.  It comes with a "FunctionMaker" utility that allows you to drop in PHP code and create custom functions for FileMaker very easily.

So at it stands now, I have a set of custom functions (actually External Functions) in FileMaker that allow me to easily make PayPal API calls.  

Within my own solutions I can actually customize the functions themselves to update my own db tables with all the response data from PayPal (ie. transaction id, timestamp, correlation id, fee information, etc.)

I'd like to distribute these functions, though, so other developers can use them the same way I do.  They really are extremely useful for anybody using FileMaker and trying to integrate with PayPal services.  My struggle is how to make all of the response data available in a way that any 3rd party developer can easily implement into their own solution.

Some of the API calls will have a bunch of response fields.  While I would typically create a complete log in my own system, I can't rely on other developers having the same table/field names.  I could even create new tables/fields if they didn't exist, but I'd rather not do that if I can avoid it because I know some developers won't like that.

So, what's a good way I can easily make all of this response data available to 3rd party developers to work into their own systems in whatever way they want?

Any information on this would be greatly appreciated.  Thanks!
Andrew Angell
Andrew Angell
  • 4
1 Solution
Will LovingPresidentCommented:
Wow, that sounds like a great set of tools. I'd be very interested in seeing and probably using it myself.

What I've see in the past with this kinds of thing is that developers include 1) an open FM file containing the necessary tables to capture responses that the user could modify or adapt, and/or, a "blackbox" file that gives the user specific inputs and delivers specific outputs. I believe  Waves In Motion's CCAuthorize plugin used to provided with both types of files.

I think as long as you make it clear what the response fields are for and the fact that changing them must be coordinated with the code in the Custom Functions, then people can be responsible for their own changes - or - they can just adapt and use your field names.

I thought about doing something like this for some time but was stymied by PayPal's rather opaque API documentation. I have a couple of questions for you about this that I'd like to discuss with you offline, if you are willing. Just click on my screen name and then click the "Hire Me" button to send me an email.
Andrew AngellCo-Owner / DeveloperAuthor Commented:
Yeah, that's basically the route I'm thinking of taking.

I was thinking of creating the file in a way that will store all of the requests/responses in separate records, but then also include a table full of global fields that would only hold the most recent request/response data so it would always be available for developers to pull from any time they want to populate their own stuff.

My custom functions also include a "related_record_id" parameter that can be used so developers can relate my table back to their own if necessary.

I appreciate the feedback.  Unless you can think of any problems with my plan I'll probably go that route.

Andrew AngellCo-Owner / DeveloperAuthor Commented:
Playing around with this now and it seems to be working as I expected, but one thing I didn't consider was that I'm going to end up with a bunch of bogus data in my Global_API_Response table.

For example, when I run a credit card I'll get back a transaction ID, AVS Code, CVV Code, etc. and my global fields will get updated accordingly.

Then lets say my next call is something simple like GetBalance where I don't get an AVS Code, CVV Code, and those types of values back, however, the global table fields would still hold values for those until they're either cleared out or replaced.  This could cause some confusion and I think it would be better if my global response table had ONLY data that was in the last API call response received.

I can't think of a way to do that, though, other than to add a bunch of Set Field script steps to set them all to empty, which I can do, but that would be very tedious.  Can you think of another way of accomplishing that?  Some way to clear all the fields in a table record, for example, so I can simply clear it out entirely with a single step prior to updating it with the most recent response data?
Andrew AngellCo-Owner / DeveloperAuthor Commented:
Nevermind that.  Found a way to do it.  I'm going to play around some more and then I'll come back and give you some points.
Andrew AngellCo-Owner / DeveloperAuthor Commented:
Thanks for the tips.  The plan seems to be working out perfectly.  I've gotten 5 of the PayPal API's implemented and tested from one of the Starter Solutions that FileMaker provides and it's working perfectly.  Won't take me long to get the rest of them done now.

I emailed you through the link you mentioned but I haven't heard from you.  Let me know if you don't see it.

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now