Forum OpenACS Development: Is there documentation for acs-service-contract?
Is there documentation available for acs-service-contract? I plan one creating an interface to an alternate credit-card gateway. Cybercash is no more and I plan on developing an interface to Authorize.net.
This is going to be quite involved as Cybercash had a unique workflow and there are several severe bugs in the ecommerce module. Gilbert Wong did an excellent job of porting the ecommerce package but these bugs are inherited from ACS 3.x.
I hope that with the acs-service-contract documentation I'll be able to get a better understanding of how to separate the credit-card handling from the rest of the ecommerce module with a clean interface.
While I'm interested in an interface to authorize.net others might be keen on different gateways. All input (and help) is welcome.
- A contract is comprised of abstract operations (e.g. search is an abstract operation of the FtsEngineDriver contract).
- An implementation of a contract maps/alias the abstract operations to concrete functions (e.g. openfts_driver__search is the alias for the search operation of FtsEngineDriver)
- You have to contact Gilbert Wong and together decide on a good set of abstract operations for credit card handling. These abstract operations comprise your credit-card-gateway contract (interface) and in order to separate credit-card handling from the rest of the ecommerce package, the ecommerce package should support this contract. I don't know to what extend Gilbert will be available to help with this one but I assume he will be more interested after the first OpenACS release.
- You have to foresee all possible implementations (e.g. verisign, authorize.net, e-clear, etc) while deciding the abstract operations.
It would be great to have payment services separated from e-commerce, since e-commerce is only one package that might make use of such a tool.
Another obvious client would be an events package, or components of a dotLRN solution where on-line registration
might be allowed, etc. Or donation handling for non-profits. The potential list is lengthy and payment services should be a central service of the toolkit.
This will also make other packages that needs credit card processing easier. Like for example making ecommerce-lite etc. Based from the my ACS 3.x stint with ecommerce I am sure that there will a lot of implementation that would not use the bagage of ecommerce.
Has anyone able to use other payment gateways in ACS 3.x?
I'm working on tying the ecommerce search function to openfts. Can you define what the impl_name and impl_owner_name are in the following sql code?
select acs_sc_impl__new( 'FtsContentProvider', -- impl_contract_name 'note', -- impl_name 'notes' -- impl_owner_name );
My first guess is that the impl_name is an identifier and the impl_owner_name is the name of the package. Is that statement correct?
Eventually, I would like to get some information on how to write a service contract. Is there any code that I can look at to see how it should be written?
Can you define what the impl_name and impl_owner_name are in the following sql code?The impl_owner_name is the package key of the package that provides the implementation (in our case
ecommerce). The impl_name should be the object_type of the items that you want to index/search. So, for example
ec_product, if you want to index/search ecommerce products. The sql code is:
Note that for FtsContentProvider to work ok, you might need to write some triggers to update the search_observer_queue table. Unless, your content items are stored in the CR, you need to write the triggers. For examples look at
select acs_sc_impl__new( 'FtsContentProvider', -- impl_contract_name 'ec_product', -- impl_name 'ecommerce' -- impl_owner_name );
Eventually, I would like to get some information on how to write a service contract. Is there any code that I can look at to see how it should be written?So far we have identified two kinds of contract:
impl_nameis an object_type: We decide on which implementation to use by computing the type from an object_id using
acs_object_util__get_object_type. FtsContentProvider is an example of this kind of contract.
impl_nameis a package_key: We decide on which implementation to use by using the value of the parameter in the dependant package (the package that uses the contract). FtsEngineDriver is an example of this kind of contract.
- Decide what the operations are.
- Decide on the message types (input/output). While message types are not being used extensively at this moment, they will soon be used to provide WSDL functionality.
- It is very important to note that once a contract is stabilized/released there is no turning back. At least it will be difficult to update all available implementations -- and probably we won't know all the implementations because people might have independantly developed their own implementations of a contract. Maybe, we should keep track of all implementations of a contract at a repository when the new openacs.org site is released so that we can inform people when something changes (I haven't thought of this very much, so if someone has a different POV please let us know).
search-sc-create.sql for the specification of FtsContentProvider and FtsEngineDriver. If you think your service contract doesn't fit in any of these categories please post more questions.