PFI to IPA - WFMSGDTL query string was not convertible

 9 Replies
 2 Subscribed to this topic
 52 Subscribed to this forum
Sort:
Author
Messages
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member

This is the WFMSGDTL to PFIMESSAGE issue when migrating flows from PFI to IPA.  I understand that WFMSGDTL is now PFIMESSAGE and/or S$PFIME, but I'm having trouble getting rid of the "Some or all of the transaction / query string was not convertible"  I've rebuilt the transaction string as described below but still have the query string error and can't get rid of it.  Is there something wrong with the landmark query is generated?  Or do I need to change it to a SQL query and join PFIMESSAGE and S$PFIME using the uniqueid?

From - OLD PFI:

PROD=LOGAN&FILE=WFMSGDTL&FIELD=MESSAGE;MESSAGE-APPEND;MESSAGEHDR.CREATED-BY; MESSAGEHDR.ATTACH-BY&SELECT=WORKUNIT=&OUT=CSV&DELIM=~

 

To - NEW IPA:

_dataArea="lawprod" & _module="pfi" & _objectName="PfiMessage" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _authenticatedUser="" & _pageSize="30" & _relationName="" & _setName="SymbolicKey" & _asOfDate="" & _effectiveDate="" & PfiWorkunit="" & AttachByName & Message

--The assumption being that Message is really the value from the S$PFIME table

 

Tim Cochrane
Veteran Member Send Private Message
Posts: 154
Veteran Member
I always rebuild messaging nodes in IPA...since there were so many changes from PFI. I can see a couple things wrongs/missing in your query: 1. Not sure why you have the relationName parameter set - you really don't need it in the example I've provided below. 2. you'll need to set "PfiWorkunit" = to something, like . 3. if you want to bring back messages for specific approvers in the workunit, you'll need to set "AttachBy" = to something, otherwise you'll bring back ALL messages for a workunit. Current client doesn't use workflow messages, but at previous client this is what we used. This was 13 months ago, but I doubt the syntax has had to change. This example assumes two things: 1. there can be multiple user actions in the flow, and 2. this query is nested inside a PfiMetrics query and is finding and assigning multiple users to the var _dataArea="" & _module="pfi" & _objectName="PfiMessage" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _pageSize=30 & _setName="SymbolicKey" & PfiWorkunit="" & AttachBy="" & Message & AttachByName & AttachDate Not sure why you want to use the "S$" components, but it's not necessary.
Tim Cochrane - Principal LM/IPA Consultant
Tim Cochrane
Veteran Member Send Private Message
Posts: 154
Veteran Member
the var names were dropped from previous post: 1. dataArea = appProdline, 2. PfiWorkunit = oWorkUnit, 3. AttachBy = userid
Tim Cochrane - Principal LM/IPA Consultant
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
Thank you Tim. I'll try deleting and rebuilding the node from scratch. It looked like S$PFIME was where the actual message was stored. There must be an implicit reference to it form the PFIMESSAGE query. I thought the variable was in the query pasted, but I can see now it wasn't. When searching for variable using CTRL-space the variable name was and not . The relationName was part of the build wizard, but I left it null. Maybe removing it from the script will help. This is what I have: where dataArea is a literal and it is the LSF dataArea which is the LMRK dataArea. _dataArea="lawprod" & _module="pfi" & _objectName="PfiMessage" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _authenticatedUser="" & _pageSize="30" & _relationName="" & _setName="SymbolicKey" & _asOfDate="" & _effectiveDate="" & PfiWorkunit="" & AttachByName & Message
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
I see why the variable wasn't pasted now. They are striped out. I'm encapsulating variable in {} Old {!oWorkUnit} New {!WorkUnit} _dataArea="lawprod" & _module="pfi" & _objectName="PfiMessage" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _authenticatedUser="" & _pageSize="30" & _relationName="" & _setName="SymbolicKey" & _asOfDate="" & _effectiveDate="" & PfiWorkunit={!WorkUnit} & AttachByName & Message
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member
Hopefully this clarifies the ctrl-space sentence. It should read: When searching for variable using CTRL-space the variable name was {!WorkUnit} and not {!oWorkUnit}. I guess the variable names are different in IPA as well.
Tim Cochrane
Veteran Member Send Private Message
Posts: 154
Veteran Member
No...unless you've been able to change the system variables, it's still "oWorkUnit". You won't find the system vars by using CTRL-Space, so most likely what you're seeing is where somebody has made the assignment WorkUnit = oWorkUnit in the Start node. You won't find oCatVal or oCatKey using CTRL-Space...but they're there and available as well. I use this byline in all my ProcessFlow emails, and oWorkUnit resolves just fine Process Flow SCSecAuto Work Unit {!oWorkUnit} Product Line {!appProdline} Email SCSecAuto01 Either way, sounds like you're on the way to getting it resolved.
Tim Cochrane - Principal LM/IPA Consultant
Tim Cochrane
Veteran Member Send Private Message
Posts: 154
Veteran Member
Correction - oWorkUnit is a Persistent global variable, not a system variable
Tim Cochrane - Principal LM/IPA Consultant
Tim Cochrane
Veteran Member Send Private Message
Posts: 154
Veteran Member
Interesting, I learned something new today... oWorkUnit IS Workunit in IPA and it does appear in the query builders when doing a CTRL-Space...makes me wonder how & why referencing oWorkUnit still works. oCatValue and oCatKey also appear in a CTRL-Space.
Tim Cochrane - Principal LM/IPA Consultant
DavidV
Veteran Member Send Private Message
Posts: 101
Veteran Member

Thank you Tim for all the input.

 

Deleting the node and reading resolved the issue.