Private use fields

[Mike Summers]

I am trying to integrate jPOS with New Relic's cross application tracing generically- that is in a way that is not sensitive to the channel or data fields used. Typically doing this means adding to the HTTP or JMS headers which creates no interaction issue with the underlying application.

Reading through the channel code is looks like I should stay away from modifying the header, that headers are channel specific. Is that a correct assumption?

Looking at the reserved fields I don't see a way to prevent a collision with the application programmer- that is really _reserving_ a reserved field.

I would appreciate any thoughts or suggestions on how to approach adding my 'header' data in a safe manner that is not application specific.

Thanks-- Mike

[Alejandro Revilla]

This is interesting and I can see how some of our customers using NewRelic could benefit from it, but it is not straight forward.

The ISO-8583 wire protocol is usually not mandated by the jPOS site where you could use NewRelic for monitoring, it's mandated by the endpoints (think VISA, MasterCard). So you can't just add a header and send it over the wire, because it will fail while the message is being received on the other end. You can't add a private field either, because the other end will notice it.

But most application messages have a field suitable for what you want, the retrieval reference number (field 37). Problem is based on a given ISO-8583 message binary image, your application would have to know the format (i.e. is it in VISA's format? is it in MasterCard's format?), open the message in order to figure out where field 37 is, and then use those 12-chars  (perhaps concatenated with the merchant (15 digits) and terminal ID (8 or 16 chars depending on the ISO version)) and use that as the X-NewRelic-ID.

Now the thing is where you run that extraction code, in your local agent? on your server? If it's on the server, you'd be getting the whole ISO-8583 message image and that contains PCI-sensitive data, so it's probably a no-go. If it's on the agent, the agent will have to be very smart to tell apart different links (i.e. a message coming from the acquirer-A on message format A versus message coming from acquirer-B using format B).

My 2c

--

@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/6cc1a880-110a-4eab-a80b-b1f2c7ff7cd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Summers]

Thanks for your thoughts Alejandro.

I should have mentioned that in the use case I'm working we're using jPOS on both sides of the connection, which is how I foresee being able to add and extract the 'header' data. The Agent lives with both the sender and the receiver.

From the technical perspective I'm planning on using a runtime aspect to intercept BaseChannel.send and BaseChannel.receive to add/extract what we need.

Thanks again for your thoughts.

On Tuesday, November 22, 2016 at 10:26:40 AM UTC-6, Alejandro Revilla wrote:

This is interesting and I can see how some of our customers using NewRelic could benefit from it, but it is not straight forward.

The ISO-8583 wire protocol is usually not mandated by the jPOS site where you could use NewRelic for monitoring, it's mandated by the endpoints (think VISA, MasterCard). So you can't just add a header and send it over the wire, because it will fail while the message is being received on the other end. You can't add a private field either, because the other end will notice it.

But most application messages have a field suitable for what you want, the retrieval reference number (field 37). Problem is based on a given ISO-8583 message binary image, your application would have to know the format (i.e. is it in VISA's format? is it in MasterCard's format?), open the message in order to figure out where field 37 is, and then use those 12-chars  (perhaps concatenated with the merchant (15 digits) and terminal ID (8 or 16 chars depending on the ISO version)) and use that as the X-NewRelic-ID.

Now the thing is where you run that extraction code, in your local agent? on your server? If it's on the server, you'd be getting the whole ISO-8583 message image and that contains PCI-sensitive data, so it's probably a no-go. If it's on the agent, the agent will have to be very smart to tell apart different links (i.e. a message coming from the acquirer-A on message format A versus message coming from acquirer-B using format B).

My 2c

--

@apr

On Tue, Nov 22, 2016 at 12:34 PM, Mike Summers <msum...@newrelic.com> wrote:

I am trying to integrate jPOS with New Relic's cross application tracing generically- that is in a way that is not sensitive to the channel or data fields used. Typically doing this means adding to the HTTP or JMS headers which creates no interaction issue with the underlying application.

Reading through the channel code is looks like I should stay away from modifying the header, that headers are channel specific. Is that a correct assumption?

Looking at the reserved fields I don't see a way to prevent a collision with the application programmer- that is really _reserving_ a reserved field.

I would appreciate any thoughts or suggestions on how to approach adding my 'header' data in a safe manner that is not application specific.

Thanks-- Mike

--
--
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.

[Alejandro Revilla]

Perhaps it's easier to create your own channel and just override getMessageLength() and sendMessageLength(), you can add your NewRelic-ID right after the length. 

You just need to use that channel (i.e. NewRelicChannel) instead of whatever they are using.

--

@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/49d4a8cd-ad7f-469e-a396-7f78407f30fc%40googlegroups.com.