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