Where to put custom translation logic in jPOS?

[Mozammel Haque]

Hi,

My team is working in a project where a request(ISO 8583) need to be send via JPOS server to the backend (Remote Host as per official doc) via SOAP api.

We have implemented our system as follows:

We implemented a ISOListner in a middleware (spring boot project) where it converts the incoming ISO message to SOAP request.

Is it possible/advisable to embed the middleware code to JPOS server itself?

If possible , what is the right place to put our translation logic ? Is it the ChannelAdaptor or TransactionManager?

Few blogs suggest that we can put all logic to TransactionManager or ChannelAdaptor. If it is true then do we need mux and channel at all? Or our architecture is ok to proceed further?

Thanks,

Moz

[Alejandro Revilla]

We usually implement a custom participant doing the SOAP/REST thing.

In the case of REST, we use Apache's HTTP Client (org.apache.httpcomponents:httpclient:4.5.5) that provides a nice async interface that works great with the TransactionManager's PAUSE.

Here is an example:

   public int prepare (long id, Serializable o) {

        Context ctx = (Context) o;

        String url = getURL (ctx);

        HttpPost post = new HttpPost(url);

        StringEntity entity = new StringEntity(ctx.getString(JSON_REQUEST.name()), ContentType.create("application/json", Consts.UTF_8));

        post.setEntity(entity);

        try {

            client.execute(post, response -> {

                int sc = response.getStatusLine().getStatusCode();

                if (sc == HttpStatus.SC_CREATED || sc == HttpStatus.SC_OK)

                    ctx.put (JSON_RESPONSE.name(), EntityUtils.toString(response.getEntity()));

                ctx.resume();

                return null;

            });

            return PREPARED | PAUSE | NO_JOIN | READONLY;

        } catch (IOException e) {

            warn (e);

        }

        return ABORTED;

    }

--

@apr

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.
To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/6158c710-b9d1-457d-a2f7-209a955ed8e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mozammel Haque]

Hi Alejandro,

Thanks a lot for your reply and clarification. So in this case, we are executing the REST call directly from TransactionManager - so for talking with a REST/SOAP clients, we don't necessarily need to use the MUX and Channel part of jPOS architecture, am I right?

Thanks,

Moz

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DxDwZ_WBhtM4Aad0dNpKrgx2aVM7mvQSUk_asyqHeqyw%40mail.gmail.com.

[chhil]

That is correct, you don't need mux/channel. Use your favorite third party  API to make those http calls directly that understands the protocol. For low level logging you will need to determine what your API has to offer. 

-chhil. 

--

@apr

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/6158c710-b9d1-457d-a2f7-209a955ed8e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DxDwZ_WBhtM4Aad0dNpKrgx2aVM7mvQSUk_asyqHeqyw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+...@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CA%2BmF82%2B0nVJjj32ArrURmnrf7hWEHYH9ehGk21Nzfjcg6C%2BUXQ%40mail.gmail.com.

[Mozammel Haque]

Thanks Chhil, this helps a lot. We are already on our way to implement an MVP with jPOS as we talked in this thread. 

--

@apr

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/6158c710-b9d1-457d-a2f7-209a955ed8e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAAgSK%3D%3DxDwZ_WBhtM4Aad0dNpKrgx2aVM7mvQSUk_asyqHeqyw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CA%2BmF82%2B0nVJjj32ArrURmnrf7hWEHYH9ehGk21Nzfjcg6C%2BUXQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

--
jPOS is licensed under AGPL - free for community usage for your open-source project. Licenses are also available for commercial usage. Please support jPOS, contact: sa...@jpos.org
---
You received this message because you are subscribed to the Google Groups "jPOS Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-users+unsubscribe@googlegroups.com.

To post to this group, send email to jpos-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jpos-users/CAPazefDK5P0yZ%2B49jv9mruosHF4Tk0zZBGxS3SHLunmq5OhVSQ%40mail.gmail.com.

[Samnang Chhun]

@apr, I'm doing similar to you by hitting a REST server with Retrofit 2 in async mode and resume the context in the HTTP callback. I couldn't figure out how to abort the participant in the HTTP callback when I got the error response from the server. Let say I check if the HTTP response code is 400 or 422 from the server, I want to the participant to return ABORTED instead of just resuming the context with PREPARED.

--

@apr

To unsubscribe from this group and stop receiving emails from it, send an email to jpos-...@googlegroups.com.

[Samnang Chhun]

@apr, I'm doing similar to you by hitting a REST server with Retrofit 2 in async mode and resume the context in the HTTP callback. I couldn't figure out how to abort the participant in the HTTP callback when I got the error response from the server. Let say I check if the HTTP response code is 400 or 422 from the server, I want to the participant to return ABORTED instead of just resuming the context with PREPARED.

Repost the question because @apr said he didn't see the message posted in the thread.

- Samnang 

[Alejandro Revilla]

You need to use the context to communicate the error to the next participant. The Pausable interface (which the Context implements) just allows you to "resume()" the transaction, all the rest of the business logic happens back in the TransactionManager, within the following participant which usually handles the response.

--

@apr

On Sat, Oct 19, 2019 at 10:38 AM Samnang Chhun <samnan...@gmail.com> wrote:

@apr, I'm doing similar to you by hitting a REST server with Retrofit 2 in async mode and resume the context in the HTTP callback. I couldn't figure out how to abort the participant in the HTTP callback when I got the error response from the server. Let say I check if the HTTP response code is 400 or 422 from the server, I want to the participant to return ABORTED instead of just resuming the context with PREPARED.

[Samnang Chhun]

Thanks for the clarification. It totally makes sense.

[Kogan Moonsamy]

Hi All,

I realise that this an old topic but quite relevant to me as we will be undertaking something very similar.

With all our other issuer channels, the mux handles the timeout. How would we handle timeouts to a REST/SOAP API without the mux?

Regards

Kogan

[Kogan Moonsamy]

I believe i may have found the solution using RequestConfig.

Thx