Re: [PROPOSAL] First Data Payment Gateway Integration

[Suraj Khurana]

+1 Nicolas.

--
Best Regards,
Suraj Khurana
Senior Technical Consultant


On Mon, Jun 15, 2020 at 8:23 PM Nicolas Malin 
wrote:

> Hi Pritam,
>
> My preference go to move all gateway to plugin, to keep OFBiz framework
> slim and the connector quality high.
>
> If all third payment gateway are in plugin system, we are sure that the
> framework contains correct standard call in function process, and we 're
> not tempted (to go fast) to introduce bad hook to support a specific
> case needed by the gateway.
>
> That being said, your proposal to introduce this gateway payment are
> welcome :)
>
> Nicolas
>
> On 15/06/2020 15:15, Pritam Kute wrote:
> > Hello Devs,
> >
> > I hope everyone is safe and well.
> >
> > Apache OFBiz has OOTB integrations for most of the widely used payment
> > gateways around the world.
> >
> > We are working on integrating First Data Payment Gateway for one of the
> > websites. The First Data payment gateway is quite popular and comes in
> the
> > list of top payment gateways around the globe  We would like to
> contribute
> > the basic payment gateway integration of First Data into Apache OFBiz. We
> > would like to know your thoughts on this.
> >
> > We would also like your opinion on contributing the gateway code in
> > applications/accounting component vs a separate plugin.
> >
> > After approval from the community, we will create detailed tickets in
> JIRA
> > and contribute the patch accordingly.
> >
> > Thanks!
> >
> > Kind Regards,
> > --
> > Pritam Kute
> >
>

Re: REST implementation

[Carsten Schinzer]

Hello,


Certainly +1 for a REST API Implementation including JWT.

I am implementing a REST API for internal use in my job based upon PHP and 
Symfony framework (FOS REST and NELMIO Bundle just in case someone is 
interested) and find VERY cool that the NELMIO API Doc Bundle comes with an 
adopted Swagger documentation done through Annotations on the documentation 
comment for the very method implementation, i.e. avoiding the various different 
files to define the invocation, URI endpoint, implementation.

A good REST API design usually obsoletes the need to include the CRUD action 
into service naming (createXService, updateYService, ...). I liked the 
following article most and have implemented along this guidelines on my 
internal tool mentioned above: 
https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api 
.

It is a bit trickier to keep a good overview of verbs & methods on such APIs, 
but that can easily be handled by warnings/errors at Integration time. And the 
generated API documentation is always your friend, too!

I would therefore prefer to combine a REST API implementation with OpenAPI 
integration right away. Maybe worth a dedicated discussion and kick-off in the 
upcoming Community Days in August? Could be worth a dedicated team / slack 
channel that aligns on major concepts and side-by-side options of Service 
Engine vs. OpenAPI and gets a first implementation going.


If we decide to take that path, there will be interference with the Service 
Engine view and the Swagger Documentation will replace it on the long run I 
would expect. We would also need to consider cross-effects onto the 
Minilang-to-GroovyDSL migration. Design and Architecture decisions made could 
mean a change of direction on that activity.

Hope my 0.02 EUR make sense.
Warm regards


Carsten


> Am 15.06.2020 um 17:59 schrieb Girish Vasmatkar 
> :
> 
> Hi All
> 
> I have tried to implement a draft proposal here -
> https://github.com/girishvasmatkar/ofbiz-rest-impl.git
> The readme contains details.
> 
> In order to support the changes, I have made a corresponding change in the
> service definition to include a new attribute named "verb". This can also
> be named "method". These changes are in my forked ofbiz repo (it is very
> much in sync with ofbiz trunk):
> https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb
> 
> Initial implementation does not contain OpenApi integration yet. And yes,
> we should be fine doing both JSON and YAML.
> 
> Please take a look at it and let me know what you think of this. I am open
> to suggestions, improvements, discussions.
> 
> Best Regards,
> Girish
> 
> 
> On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute 
> wrote:
> 
>> Hello Girish,
>> 
>> +1 for having REST implementation using Jersey as a separate plugin and not
>> to disturb the OFBiz default Control servlets and filters.
>> 
>> IMO we should also think about the end-point security implementations
>> alongside as it is one of the crucial things that users look into while
>> adopting any framework.
>> 
>> Kind Regards,
>> --
>> Pritam Kute
>> 
>> 
>> On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>> 
>>> 
>>> Hi Girish,
>>> 
>>> Inline...
>>> 
>>> Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit :
 Hi All
 
 I am again bringing up this discussion on having a REST implementation
>>> for
 OFBiz. I know we have had discussions before and I was looking at some
>> of
 the past discussions about this topic and seems we are not there quite
>>> yet
 (correct me if I am wrong).
 
 I had developed a POC plug-in based on Jersey (that I am currently
 enhancing) and recently started evaluating Apache Juneau as well. I
>>> wanted
 to bring everybody on the same page as far as REST implementation is
 concerned so I had initiated a discussion on slack today. I am listing
>>> down
 a few points below that can be perceived as
>>> comment/question/understanding
 based on my general understanding of the matter and today's slack
 discussion.
 
- Anything we start on can be part of a plug-in for the start and
>>> later
can become part of the framework (as separate plug-in) once it is
developed. A dedicated API application will allow it to be
>>> lightweight in
terms of request processing. Should have separate auth mechanism
>>> bypassing
ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
>>> the API
request to go through these three. Please correct me.
>>> 
>>> Though I did not look at the code (is it already somewhere?) I tend to
>>> agree on that.
>>> REST is something else and should not be hampered by those, if it's the
>>> case.
>>> 
>>> 
- We want to have mechanism to expose services (export=true) to be
available as a REST resources. Possibly extending 

OFBiz Coding Conventions

[Carsten Schinzer]

Hello all,


Like many of you, I am currently working on a piece to move services from 
minilang to Groovy DSL.
When looking around in the Wiki I found that the Coding Conventions 
(https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions 
) do have 
a foreseen section for „Service Definitions“, yet it is entirely empty.

As I also observe some deviations across the various file types and names 
involved with service definition and also inconsistencies with file locations 
in packages (Groovy-based test cases belong to non-test packages) I wondered 
where it is possibly a good time — now that plenty of us are working on the 
Mining to Groovy DSL migration — to align on conventions related to:
* Services Naming
* Context Definitions, e.g. sequence of IN vs OUT variables in seca definitions
* location of service implementations vs test implementations
* ...

I am sure there are already plenty mutually agreed conventions being „gate 
kept“ by the committers, yet I would prefer to make them explicit and document 
them for everyone’s benefit.

Note sure how to track this further … I can propose to consolidate replies to 
this mail thread and update the page as well as monitoring the page itself 
where you might leave comments or add updates to the section yourselves.

What do you think?

Warm regards from rainy Munich


Carsten

Re: REST implementation

[Girish Vasmatkar]

Hi All

I have tried to implement a draft proposal here -
https://github.com/girishvasmatkar/ofbiz-rest-impl.git
The readme contains details.

In order to support the changes, I have made a corresponding change in the
service definition to include a new attribute named "verb". This can also
be named "method". These changes are in my forked ofbiz repo (it is very
much in sync with ofbiz trunk):
https://github.com/girishvasmatkar/ofbiz-framework/tree/feature/add-service-verb

Initial implementation does not contain OpenApi integration yet. And yes,
we should be fine doing both JSON and YAML.

Please take a look at it and let me know what you think of this. I am open
to suggestions, improvements, discussions.

Best Regards,
Girish


On Mon, Jun 15, 2020 at 7:02 PM Pritam Kute 
wrote:

> Hello Girish,
>
> +1 for having REST implementation using Jersey as a separate plugin and not
> to disturb the OFBiz default Control servlets and filters.
>
> IMO we should also think about the end-point security implementations
> alongside as it is one of the crucial things that users look into while
> adopting any framework.
>
> Kind Regards,
> --
> Pritam Kute
>
>
> On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> >
> > Hi Girish,
> >
> > Inline...
> >
> > Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit :
> > > Hi All
> > >
> > > I am again bringing up this discussion on having a REST implementation
> > for
> > > OFBiz. I know we have had discussions before and I was looking at some
> of
> > > the past discussions about this topic and seems we are not there quite
> > yet
> > > (correct me if I am wrong).
> > >
> > > I had developed a POC plug-in based on Jersey (that I am currently
> > > enhancing) and recently started evaluating Apache Juneau as well. I
> > wanted
> > > to bring everybody on the same page as far as REST implementation is
> > > concerned so I had initiated a discussion on slack today. I am listing
> > down
> > > a few points below that can be perceived as
> > comment/question/understanding
> > > based on my general understanding of the matter and today's slack
> > > discussion.
> > >
> > > - Anything we start on can be part of a plug-in for the start and
> > later
> > > can become part of the framework (as separate plug-in) once it is
> > > developed. A dedicated API application will allow it to be
> > lightweight in
> > > terms of request processing. Should have separate auth mechanism
> > bypassing
> > > ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
> > the API
> > > request to go through these three. Please correct me.
> >
> > Though I did not look at the code (is it already somewhere?) I tend to
> > agree on that.
> > REST is something else and should not be hampered by those, if it's the
> > case.
> >
> >
> > > - We want to have mechanism to expose services (export=true) to be
> > > available as a REST resources. Possibly extending existing service
> > > definition by a new attribute verb="get|post".
> >
> > +1
> >
> >
> > > Also, if we also want to
> > > expose out REST interface as an OpenApi specification, then it will
> > > possibly help if we show in the spec an example of request for a
> > specific
> > > service. In that case, the service definition can be expanded to
> > allow for
> > > defining a JSON example (in a CDATA element)?
> >
> > That's an interesting point. Maybe we could prefer YAML over JSON.
> > Because YAML is a superset of JSON and that could be useful in future:
> >
> >
> https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json
> > But it might complicate things in request bodies...
> >
> >
> > > -  Any service that declares one of the verbs and not called with
> > > declared verb will result in 405(Method not found) or 404(Resource
> > does not
> > > exist) error.
> > >- GET /api/services/{serviceName}?inParams={JSON}
> > >- POST /api/services/{serviceName} (Request Body will contain in
> > >params as JSON)
> > >- GET /api/services : We list all services(export=true) along
> with
> > >HATEOS Links (self link describing where the specific service
> can
> > be
> > >located)
> >
> > +1
> >
> >
> > > - Do we want to have a similar resource for entities?. I think
> > entities
> > > should not be exposed directly as a REST resource even though they
> > are a
> > > good example of being a resource.
> > > - We can take one day at a time approach here and just start with
> > > exposing services as REST.
> >
> > I agree, can be decided later...
> >
> >
> > > - Auth : I had provided JWT based auth for the plug-in I had
> > developed.
> >
> > Sounds good to me.
> >
> >
> > > This can further be expanded and allow for Digest auth as well? Can
> > have
> > > separate API endpoint to generate JWT token.
> >
> > That could definitely be interesting.
> 

Re: [PROPOSAL] First Data Payment Gateway Integration

[Nicolas Malin]

Hi Pritam,

My preference go to move all gateway to plugin, to keep OFBiz framework
slim and the connector quality high.

If all third payment gateway are in plugin system, we are sure that the
framework contains correct standard call in function process, and we 're
not tempted (to go fast) to introduce bad hook to support a specific
case needed by the gateway.

That being said, your proposal to introduce this gateway payment are
welcome :)

Nicolas

On 15/06/2020 15:15, Pritam Kute wrote:
> Hello Devs,
>
> I hope everyone is safe and well.
>
> Apache OFBiz has OOTB integrations for most of the widely used payment
> gateways around the world.
>
> We are working on integrating First Data Payment Gateway for one of the
> websites. The First Data payment gateway is quite popular and comes in the
> list of top payment gateways around the globe  We would like to contribute
> the basic payment gateway integration of First Data into Apache OFBiz. We
> would like to know your thoughts on this.
>
> We would also like your opinion on contributing the gateway code in
> applications/accounting component vs a separate plugin.
>
> After approval from the community, we will create detailed tickets in JIRA
> and contribute the patch accordingly.
>
> Thanks!
>
> Kind Regards,
> --
> Pritam Kute
>


pEpkey.asc
Description: application/pgp-keys

Re: REST implementation

[Pritam Kute]

Hello Girish,

+1 for having REST implementation using Jersey as a separate plugin and not
to disturb the OFBiz default Control servlets and filters.

IMO we should also think about the end-point security implementations
alongside as it is one of the crucial things that users look into while
adopting any framework.

Kind Regards,
--
Pritam Kute


On Fri, Jun 12, 2020 at 2:58 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> Hi Girish,
>
> Inline...
>
> Le 10/06/2020 à 17:42, Girish Vasmatkar a écrit :
> > Hi All
> >
> > I am again bringing up this discussion on having a REST implementation
> for
> > OFBiz. I know we have had discussions before and I was looking at some of
> > the past discussions about this topic and seems we are not there quite
> yet
> > (correct me if I am wrong).
> >
> > I had developed a POC plug-in based on Jersey (that I am currently
> > enhancing) and recently started evaluating Apache Juneau as well. I
> wanted
> > to bring everybody on the same page as far as REST implementation is
> > concerned so I had initiated a discussion on slack today. I am listing
> down
> > a few points below that can be perceived as
> comment/question/understanding
> > based on my general understanding of the matter and today's slack
> > discussion.
> >
> > - Anything we start on can be part of a plug-in for the start and
> later
> > can become part of the framework (as separate plug-in) once it is
> > developed. A dedicated API application will allow it to be
> lightweight in
> > terms of request processing. Should have separate auth mechanism
> bypassing
> > ControlerServlet/ContextFiler/ControlFilter. I opine we do not need
> the API
> > request to go through these three. Please correct me.
>
> Though I did not look at the code (is it already somewhere?) I tend to
> agree on that.
> REST is something else and should not be hampered by those, if it's the
> case.
>
>
> > - We want to have mechanism to expose services (export=true) to be
> > available as a REST resources. Possibly extending existing service
> > definition by a new attribute verb="get|post".
>
> +1
>
>
> > Also, if we also want to
> > expose out REST interface as an OpenApi specification, then it will
> > possibly help if we show in the spec an example of request for a
> specific
> > service. In that case, the service definition can be expanded to
> allow for
> > defining a JSON example (in a CDATA element)?
>
> That's an interesting point. Maybe we could prefer YAML over JSON.
> Because YAML is a superset of JSON and that could be useful in future:
>
> https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json
> But it might complicate things in request bodies...
>
>
> > -  Any service that declares one of the verbs and not called with
> > declared verb will result in 405(Method not found) or 404(Resource
> does not
> > exist) error.
> >- GET /api/services/{serviceName}?inParams={JSON}
> >- POST /api/services/{serviceName} (Request Body will contain in
> >params as JSON)
> >- GET /api/services : We list all services(export=true) along with
> >HATEOS Links (self link describing where the specific service can
> be
> >located)
>
> +1
>
>
> > - Do we want to have a similar resource for entities?. I think
> entities
> > should not be exposed directly as a REST resource even though they
> are a
> > good example of being a resource.
> > - We can take one day at a time approach here and just start with
> > exposing services as REST.
>
> I agree, can be decided later...
>
>
> > - Auth : I had provided JWT based auth for the plug-in I had
> developed.
>
> Sounds good to me.
>
>
> > This can further be expanded and allow for Digest auth as well? Can
> have
> > separate API endpoint to generate JWT token.
>
> That could definitely be interesting.
>
>
> >
> > Please share your thoughts on this and apologies for long email.
>
> Don't apologize, perfect summary to me :)
>
> Thank you, this is long awaited and game changing feature!
>
> Jacques
>
> >
> > Best Regards,
> > Girish
>
>

[PROPOSAL] First Data Payment Gateway Integration

[Pritam Kute]

Hello Devs,

I hope everyone is safe and well.

Apache OFBiz has OOTB integrations for most of the widely used payment
gateways around the world.

We are working on integrating First Data Payment Gateway for one of the
websites. The First Data payment gateway is quite popular and comes in the
list of top payment gateways around the globe  We would like to contribute
the basic payment gateway integration of First Data into Apache OFBiz. We
would like to know your thoughts on this.

We would also like your opinion on contributing the gateway code in
applications/accounting component vs a separate plugin.

After approval from the community, we will create detailed tickets in JIRA
and contribute the patch accordingly.

Thanks!

Kind Regards,
--
Pritam Kute

Re: Use Compound Widget on rest of the project

[Nicolas Malin]

Hi,

Compound widget is interesting from my view in final component, where
your code is closer than business cover so limited to reuse.

For the "middle-ware" component, I have a doubt about the must valuable
to convert it or how to convert it. To organize by compound widget maybe
introduce to globalize by process and not by functional entities.

After review your first commit [1] my feeling were decreased code
visibility with the namespace representation, swaying with regroup all
element that simplify the code navigation. Finally is that the problem
to improve the code navigation throw ide plugin and keep each xml as low
as possible (for the middle-ware component) and exploit compound widget
on plugin to indicate another way to concentrate business code ?

Nicolas

[1]
https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;a=blob;f=applications/order/widget/ordermgr/FindRequestCompound.xml;h=114e9c6d071a192d80e6278ba3e2c713f9ca1b17;hb=28809d7

On 14/06/2020 08:47, Jacques Le Roux wrote:
> Hi James,
>
> I see you pushed changes for FindRequest. Maybe we should wait a bit
> feedback from others?
>
> Jacques
>
> Le 14/06/2020 à 05:18, James Yong a écrit :
>> Hi Jacques,
>>
>> Ok, I created OFBIZ-11821 for this.
>>
>> Regards,
>> James
>>
>> On 2020/06/13 18:03:21, Jacques Le Roux
>>  wrote:
>>> Hi James,
>>>
>>> As a 1st thought I'd see no problem with that.
>>>
>>> Jacques
>>>
>>> Le 13/06/2020 à 14:32, James Yong a écrit :
 Hi all,

 Currently, compound widget tag is only used in Examples application.
 Propose to convert rest of the project to use compound widget, so
 that dependencies are grouped together.

 Regards,
 James
>>>


pEpkey.asc
Description: application/pgp-keys

Re: Use Compound Widget on rest of the project

[Olivier Heintz]

Hi James,

It's a good idea, but question is, how to group ?
I have tested compound Widget for the POC VueJs, and I use it with one compound 
widget file by resouceName (on a REST uri format point of view). In
example, 4 files: Example, ExampleItem, ExampleFeature, ExampleFeatureAppl
I'm waiting for more time using them to say if it's the correct group size or 
not.

So I suggest to use compound Widget, but not convert all xml files immediately, 
we need more developer experience to find the correct group size.

Regards,
Olivier

Le 13/06/2020 à 14:32, James Yong a écrit :
> Hi all,
> 
> Currently, compound widget tag is only used in Examples application.
> Propose to convert rest of the project to use compound widget, so that 
> dependencies are grouped together.
> 
> Regards,
> James 
>