Homepage › Clovertech Forums › Cloverleaf › needing pdl for Experian eligibility epic query interface going thru cloverleaf
- This topic has 10 replies, 4 voices, and was last updated 4 months, 1 week ago by
John Mercogliano.
-
CreatorTopic
-
April 9, 2024 at 3:42 pm #121304
Nancy McDaniel
ParticipantWe are looking at sending Experian eligiblity query X12 messages and they are wanting different begin/end characters than what we are using currently (what is the standard begin char -> binary VT and end char 28 -> binary FS).
Does anyone have a pdl for Experian that would do the following? Begin char (2 -> binary STX) and End char (3 -> ETX)?
-
CreatorTopic
-
AuthorReplies
-
-
April 9, 2024 at 3:52 pm #121305
Jim Kosloskey
ParticipantNancy,
What release of Cloverleaf? On 2209 (and perhaps earlier) there is an option to specify the encapsulation characters in the TCP/IP Configuration.
If you have that, perhaps that will do what you want.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
April 9, 2024 at 4:04 pm #121306
James Cobane
ParticipantAttached is a .zip file containing the .pdl and .pdo file that I believe we created when we had connected to Experian. We currently use this for our connection to Passport.
You may want to do your own compile of the .pdl to create the .pdo in your environment.
Hope this helps.
Jim Cobane – Henry Ford Health
Attachments:
You must be logged in to view attached files. -
April 9, 2024 at 5:00 pm #121308
Nancy McDaniel
ParticipantJames – I recompiled the X12_tcp.pdl and set the thread sending data to Experian to use the X12_tcp.pdl. That seemed to work as we got the TA1 from them. We send that back to the query interface on Epic. We are asking them to send us eligibility data now that it looks like we resolved the protocol transmit begin/end blocks for them.
So far, it looks like it is working and I appreciate the help on this.
-
This reply was modified 5 months ago by
Nancy McDaniel.
-
This reply was modified 5 months ago by
-
April 29, 2024 at 4:09 pm #121336
Nancy McDaniel
ParticipantNeeding assistance. We were able to use the x12_tcp.pdl when testing.
The issue is when we went to production, we discovered Experian is using multiple servers and only one was able to send data, the other was getting connection refused.
So then we tried switching over to multi-server option. We had used it a couple of times for Epic interconnect interfaces with high volume. The issue is that the info we had gotten on setting up multi-server was using the tcp protocol instead of the pdl-tcpip protocol and then using default of mllp in encapsulation configuration.
We would like to use the multi-server option for the listening thread but have a question on what the setup should be since Experian uses different start and end block.
The PDL has STX for start and ETX for end. I tried using that in the encapsulation wrapper but it did not recognize the wrapper. Debug definitely shows Experian sending 02 for begin block and 03 for end block. I then tried setting the start to 02 and end to 03. But it is still not recognizing the data. 02 hex = STC ascii and 03 hex = ETX ascii.
Any suggestions on getting the multi-server option working for Experian X12 using tcp protocol instead of the pdl-tcpip is greatly appreciated.
-
April 29, 2024 at 4:24 pm #121337
Jim Kosloskey
ParticipantNancy,
So, are you saying you tried multi-server with PDL Tcp/IP thread and that did not work or are you saying you do not know that PDL Tcp/IP can be multi-server?
I would imagine if the PDL you are using when in a single server mode is working, it should also work in multi-server mode.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
April 29, 2024 at 5:00 pm #121338
Nancy McDaniel
ParticipantJim – yes we tried the multi-server with PDL tcp/ip thread.
Note this is the input (response) thread from Experian.
When I changed it from server mode to multi-server and went into multi-server config – only change was to click on option to save IP and port.
We then got the following error – message in error state.
Unable to write message as connection no longer available — retries disabled.
Attachments:
You must be logged in to view attached files. -
April 29, 2024 at 5:10 pm #121340
Jim Kosloskey
ParticipantNancy,
I see your Maximum Clients is set to zero. I think that will not let anyone connect. Have you tried setting that to 1 or more?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
April 29, 2024 at 5:16 pm #121341
Jim Kosloskey
ParticipantNancy,
I have not worked with Experian but are you saying they are using 2 threads? One for sending the 280 and another for receiving the 281 (asynchronous message exchange) or are they wanting one thread with which to receive the 280 and return the 281 (synchronous message exchange)?
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
April 29, 2024 at 6:20 pm #121342
Nancy McDaniel
ParticipantJim,
We have several connections with them – we have one that we send data to them and that is successful.
this thread is elg_271_in which is the one that we are listening for messages from Experian. They did some initial testing and it worked.
But when we went live with them today, we found out that there are doing load balancing and sending data from multiple servers. They said they are seeing a lot of connection refused messages.
that is why we decided to try the multi-server configuration.
We have 2 multi-server input threads – Epic interconnect to our cloverleaf server with high volume. Epic provide guidance – they recommended do not set the max client setting – so we have it at zero and it works great. We did have to switch to the tcp protocol instead of the pdl-tcpip protcol but we were able to use the default MLLP protocol setting.
Your suggestion of bumping up the max client did not work.
We are getting the data but it goes to the error database with error 418 unable to write message as connection no longer available — retries disabled.
I can put in a support ticket and see if they can help me with this error.
-
May 1, 2024 at 9:08 am #121349
John Mercogliano
ParticipantThat error you are getting is an indication that the vendor has closed the connection before you sent back the reply. This can be caused by two things possibly that I’m aware of, either you are waiting on the reply from a downstream system and it is taking to long to come back or the reply proc is not copying the driver ctrl from the data message to the reply so it’s not going back on the same port it came in on.
John Mercogliano
Sentara Healthcare
Hampton Roads, VA
-
-
AuthorReplies
- You must be logged in to reply to this topic.