Hey Mario, It's still not entirely clear to me what the payment system expects.
We have experience with two different types of systems: - systems that require the user's browser to be redirect to a payment site where the user will have to confirm the transaction (sometimes being redirect further to their online bank system for 3D verification). E.g. this is how Paypal typically works. - systems where you capture all the relevant information inside your own web application, and you deal with the 3rd party payment system purely using web services. The user does not leave your application. In the first case, there are different variants, but typically it involves use of static or dynamic WResource's to handle the redirect from the third party system back to the wt application. This approach is a bit more complicated with a Wt application because it's a single-page application. In the second case, it's quite simpler. You only need to a use a HTTP client to interact with the 3rd party web services. As wim said, the http client is asynchronous, but you can follow the pattern as explained in the Http::Client documentation with deferRendering() and resumeRendering() to fix easily integrate it in a Wt application. This approach works okay as long as you expect the web services to respond quickly. Otherwise it's better to user server push instead of deferRendering() to not block your UI while you are waiting for the web service to respond. Regards, koen 2015-08-10 19:59 GMT+02:00 Mario Diethelm Guallar <mariodiethe...@gmail.com>: > Thank you Wim. I will work following your recommendations. > > As far as I understand, to use a WResource I should notify the third party > CGI module (end_transaction) the suggestedFileName that I decide to assign > to the WResource object (equivalent to the ASP script file name) and > implement the handleRequest function to manage the request/response logic. > What kind of DispossiontType should I use for the WResource (Inline or > Attachment) ? > > Regarding the done() signal, if I am not misunderstanding your suggestion > and the Http::Client example, the Wt library will trigger the done() signal > when the running WServer receives the third party answer. Is that correct? > > Thanks again. Regards. > > ________________________ > Mario Diethelm Guallar > > > > ------ Original Message ------ > From: "Wim Dumon" <w...@emweb.be> > To: "Mario Diethelm Guallar" <mariodiethe...@gmail.com>; > witty-interest@lists.sourceforge.net > Sent: 10-08-2015 07:25:43 > Subject: Re: [Wt-interest] HTTP question > > > Hello Mario, > > To process the result, you can as well use a WResource from Wt instead of > the ASP script. > > To know when the request was finished and to act on the response of a > request, connect a method to the 'done()' signal of the client. See also the > code example in Http::Client. > > Best regards, > Wim. > > > On 6 August 2015 at 01:15, Mario Diethelm Guallar <mariodiethe...@gmail.com> > wrote: >> >> Hi, >> >> I am working on the integration of a Wt application (running on an IIS >> server under Windows) with a third party local payment system. This payment >> system uses two CGI modules to first start and then return payment >> transaction results. In a nutshell it works as follows: >> >> - you have to call the first CGI module (start_transaction.cgi) from a >> dynamic Web page using an HTTP POST method with some parameters that you >> would normally get from the user (transaction amount, user account id and >> stuff like that) >> - the local payment system validates and processes the request and then a >> second CGI module (end_transaction.cgi), informs back transaction results. >> To do that, this second CGI module expects a dynamic Web page (.ASP, .PHP or >> other similar) that is invoked by the end_transaction.cgi module and where >> you can access transaction payment results and complete the transaction with >> the corresponding answer acknowledge >> >> I am planning to use Wt:Http::Cient and Wt::Http::Message classes to >> implement this application protocol and I would like to validate some of my >> assumptions: >> >> - to activate the first CGI module, I am planning to use the >> Wt::Http::Client post(url, message) function, where url is the web address >> of start_transaction.cgi and message is a Wt::Http::Message object with all >> the requested parameters loaded as "headers" (name, value pairs). >> - to process the results, I am planning to build a little ASP script (the >> one that will be used by end_transaction.cgi) that would recover all the >> information from the answer and would send it back to the Wt application >> using an HTTP POST method >> >> Does it make sense to you? As far as I understand the Wt::Http::Client >> post is an asynchronous method so I am a little bit confused about how to be >> sure if the first CGI module actually runs and what Http::Client method do I >> have to use to get the answer from the ASP script processing the second CGI >> module response. Is it possible, as an alternative answer processing method, >> to inform the Wt running application as the dynamic Web page expected by >> end_transaction.cgi? If this is feasible, what object and method do you have >> to use to wait for this answer? >> >> I would appreciate your comments. >> >> >> Thanks. Regards. >> >> >> ________________________ >> Mario Diethelm Guallar >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> witty-interest mailing list >> witty-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/witty-interest >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest > ------------------------------------------------------------------------------ _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
