PHINMS message handler

[Christina Crawford]

Does anyone out there use CDC PHINMS message handler plug in with PHINMS 2.9 or the new 3.1?

We have it installed with the new PHINMS 3.1 that has to be installed by 06/30/2019. 

The PHINMS message handler document says it can do a file folder copy from source to target AND also a database table copy from source to target.

We can only get the file folder copy to work with our PHINMS receiver service map 'payload to disk' checked.

We have PHINMS receiver setup with a PHINMS message handler. 

We have ‘payload to disk’ and ‘text payload’ boxes checked on our PHINMS receiver service map.

 

I think we need some more explanations on how the PHINMS Receiver settings and PHINMS message handler works and needs to be setup for these items to work.

 

• After we receive a file via PHINMS receiver, our internal user would like to see the actual file contents in the database table column payloadtextcontect AND also in a file in a file folder when using ‘payloadtodisk’ checked in PHINMS receiver service map.  Is this possible?
• Isn’t PHINMS message handler supposed to be able to do file folder copying AND database table copying at the same time with source and target items configured?

We noticed that we have to have the PHINMS receiver service map ‘payload to disk’ box checked for the PHINMS message handler file folder copying function to work. 
Why is the file name to the file put to the …\shared\receiverincoming file folder only contain numbers with no file extension?  Shouldn’t the original file name and file extension be used?

How do we get the original file name and file extension copied to the target file folder instead of just a number as the file name with no file extension?

• Shouldn’t an external file folder path be used in the target file folder in the PHINMS message handler?  We had to map a drive and use the mapped drive in the PHINMS message handler target file folder configuration.
• In PHINMS receiver service map if have ‘pay load to disk’ box checked and ‘text payload’ box checked and have PHINMS message handler setup for database copying and file folder copying:
• Can the file content be put into the source database table payloadtextcontent column, then be copied to the target database table if PHINMS message handler setup that way?
• There is no application-context_readme.txt file in the message handler directory to refer to as mention in PHINMS message handler documentation.
• If there are errors, shouldn’t the PHINMS message handler be writing to the error database table configured in the config.properties file?  Should error emails also be sent? 

 

Thanks,

Christina

 

[Preacher Man]

Christina,

I've been away from this for several years now, but here are my general recollections.  Hopefully others will jump in and correct or augment my comments.

Generally speaking, the PHINMS "message handler" as typically  identified by the <defaultsevice><defaultaction> pair has limited capabilities. You can choose one payload destination, but must write your own software for additional actions.  For example a database service that would copy payloads from the dB to disk (check with your enterprise dB group), or a file service that could stuff a disk file into the database (check with an application programmer). 

The third approach (which I used) was to write your own custom message handler. Then you can (for example) write to any file name or folder you choose (like using the file name from the message meta data). You can find examples in some of my code on GITHUB. There is also third party software that is capable of reading/writing PHINMS tables.  Others may comment on that.

Of course none of this is trivial or "out of the box" stuff. On to your specific questions:

After we receive a file via PHINMS receiver, our internal user would like to see the actual file contents in the database table column payloadtextcontect AND also in a file in a file folder when using ‘payloadtodisk’ checked in PHINMS receiver service map.  Is this possible? Not using the stock handler - see my general comments above.

Isn’t PHINMS message handler supposed to be able to do file folder copying AND database table copying at the same time with source and target items configured? Same as your first question - see above.

We noticed that we have to have the PHINMS receiver service map ‘payload to disk’ box checked for the PHINMS message handler file folder copying function to work.  

Why is the file name to the file put to the …\shared\receiverincoming file folder only contain numbers with no file extension?  Shouldn’t the original file name and file extension be used? PHINMS does this to insure that every received payload gets a unique name and doesn't clobber an existing payload.  Believe it or not, some clients use the SAME NAME for every payload, even though the content changes.  I know... crazy, eh?

How do we get the original file name and file extension copied to the target file folder instead of just a number as the file name with no file extension? See general comments above.

Shouldn’t an external file folder path be used in the target file folder in the PHINMS message handler?  We had to map a drive and use the mapped drive in the PHINMS message handler target file folder configuration. The receiver.xml configuration contains an <incomingDir> tag that identifies the default destination folder. This can be anywhere, but must have r/w permissions set for the PHINMS service(s).  You can modify this somewhere in the receiver's GUI.

In PHINMS receiver service map if have ‘pay load to disk’ box checked and ‘text payload’ box checked and have PHINMS message handler setup for database copying and file folder copying:

Can the file content be put into the source database table payloadtextcontent column, then be copied to the target database table if PHINMS message handler setup that way? Same as your first question - see above.

There is no application-context_readme.txt file in the message handler directory to refer to as mention in PHINMS message handler documentation.

If there are errors, shouldn’t the PHINMS message handler be writing to the error database table configured in the config.properties file?  Should error emails also be sent? I don't know about either the readme or config you refer to. PHINMS should be writing errors to the alarms tables. For the receiver this is identified in the <alarms><dbDir> tag. I have not had any luck modifying this, but others may be able to help. However, if the error results from some un-handled JAVA exception, it never gets written. You will only see it in the Tomcat server log(s) (rather than a PHINMS application log). Emails must be configured, but again only get sent if the error (exception) is handled by PHINMS.

Tom

---

From: phi...@googlegroups.com <phi...@googlegroups.com> on behalf of Christina Crawford <ccrawf...@gmail.com>
Sent: Tuesday, March 5, 2019 2:29 PM
To: PHINMS User Community
Subject: PHINMS message handler

 

--

---
You received this message because you are subscribed to the Google Groups "PHINMS User Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phinms+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.