With apologies to the Double Rainbow guy, I'm more excited about Federico's Double Forward. In a previous post, I laid out when and how to forward a transaction from one jPOS TransactionManager ('TM') to another. Now, in our Pharmacy Adjudication and Local Editing implementation, we have a need for a Double Forward, i.e, one TM forwards to another, which in turn forwards to yet another. Here, I lay out the details of Federico's nice little implementation of that requirement.
Over the past couple of years, we've refined our TM implementations such that a main TM - acting as a 'dispatcher' - pulls the requests from the inbound server queue, determines the transaction category, and the forwards to a second TM that acts as a worker. In our financial implementation, for example, a Main TM parses and identifies the transaction and then forwards it to a Credit/FSA TM, Debit/EBT TM, or Stored Value TM (partial list) depending on the transaction type. [See this post for some comments about how we implemented FSA in the TM.]
So, here are the significant parts of the Main TM here in our Pharmacy implementation:
In the place I've marked 'A', we forward some incoming transactions to an Rx Simulator we've built. At point 'B', we do a case switch (based on the value the NCPDP Transaction Type) to either forward to our Local Editing TM or our Formatting TM. For the record, the forwarding groups look like this:
Let's follow the Forwarding TM, because that's where the second forward takes place. Here's the Formatting TM:
A: Here's our double forward - if we can't format the transaction for adjudication here in our environment (i.e., if we've not been provided formatting instructions), then we forward to the Stratus TM (more on that in a bit).
B: We've put a concept in place called 'Transaction Regulator.' As you can see here, results emanating from the regulator can change transaction flow. [I'll have more to say on the Regulator in a subsequent post.]
C: Here's a nice Select Endpoint. You can see that we query either eRx (owned by Emdeon) or Relay Health to adjudicate the claim. A neat addition here: this is a test TM that provides our customers the ability to reach the production eRx and Relay systems from their test and QA installations, thus the 'T2P' ("Test To Prod") option for both.
D: Here's the forward to the Stratus TM.
E: Note the 'Stats Collector' reference. More on that in a subsequent post.
Finally, here's the bits of the Stratus TM of interest:
A: We used the 'STRATUSP3.TXN' queue to forward.
B: Pretty neat little thing here...if we are sending the transaction to the Stratus (the legacy environment), it has to look to that application like it came from the origination point...including sending it to the 'right port'...what I call our "port in, port out" implementation. To that end, we've stuck the inbound port in the transaction context ('PORT') and then use that value here to branch to the right 'query host.' [Note: the '@' variable values shown here are resolved at build time.]
C: Here we start the queries to the various Stratus destinations. [We use the one-shot channel adapter here.]
Recent Comments