DB View over Work Center Messages

joliver

Member
Can anyone help me with this? I want to generate a report based on the employee work center tables. Specifically, I want tp produce a report listing the errors and warnings from an EDI upload run (R47011). It looks like the F01131 and F01131M sort of have what I want, but I cannot see any keys that relate the two files. Also, I cannot see how to relate the F01131 to an instance of the R47011 having run. Any guidance on how I can access this info would be much appreciated!

TIA,

JohnO
 
There is a document in the JDE KG that addresses purging of the work center and lists the tables that get purged. The document is called "Procedures to Purge Workflow and Work Center Tables". The report you are referring to does not seem to provide the level of detail that is in a R47011 work center error. However, you could easily write your own report.

Lynn

Xe SP17.1, Upd 2, AIX4.3.3, Oracle 8.1.6
 
Hi John,

You should be able to do this. The files used for messaging are:

F01131 - Message headers
F01131T - Message Tag file
F01131M - Multi Level messages
F01133 - Detail
F00165 - Media objects - Normally used for holding attachments but also stores the message details.

The F01131 stores the upper levels of text you see in the work centre and the F00165 the message body.

Data item SERK (serial number) is the key between the F0113* files.

The long variable string field GDTXVC in the F00165 holds the messages your likely to need. Retrieve these using GDOBNM = "GT01131" and GDTXKY = F01131.ZZSERK.

If your doing this from within RDA try using the Media function system function to retrieve the F00165 text.

Regards

Neil.



OW B733.2, SP 11.1
Sun Solaris/UNIX
 
hi,

We have the similar requirement like we want retrieve the messages for revision program R4101Z1I.
is there any way by which we can retrieve the the ZZSERK(serial number) for a job number.
i am not able to find the relation between job no and serial no in any F0113* table.
To apply the "GDOBNM = "GT01131" and GDTXKY = F01131.ZZSERK" first we should know the ZZSERK for a particular
job number.

any suggestion or pointer would be great help for us.

we have following JDE setup
JDE812,tool set 8.96, SQL server, Windows, web client

Thanks in advance
Narendra
 
I found it difficult to join on the GDTXKY = F01131.ZZSERK.

Instead I had to hard code the join GDTXKY = 38494455

Using AS/400 DB2 database with Websphere, JDE900, tools 8.98.4

Looks like these work centre tables on our system could be purged every now and then.

Someone is giving a presentation at this year's InSync11 conference in Sydney Australia about this very topic. How to modify the R47011 PDF output to include workcentre messages.
 
Automation,

[ QUOTE ]
Someone is giving a presentation at this year's InSync11 conference in Sydney Australia about this very topic. How to modify the R47011 PDF output to include workcentre messages.

[/ QUOTE ]

That would be me.

The presentation is entitled:

Include Work Centre Error Messages in Logs When Importing Transactions Via ‘Z’ Tables

The abstract is:

<font color="green"> It can be frustrating when a transaction import fails and you need to go to the work centre and open all the nodes to get the base errors. The work centre error messages can be put into a log created during the importation processing. The log can then be emailed to the user or perhaps used to create a Help Desk Call. This is enabled by having a master UBE run the entire import process, including the loading of the "Z" tables then processing the data into the normal JDE tables. There are a couple of custom NER business functions that are used in the process that may be used for other purposes as well. </font>

However, the detail could probably be adapted to the R47011

If a Work Centre report is needed, there is a custom Work Centre UBE (in a Boomerang package thanks to Alex Pastuhov, Everest Software International) attached to a post in Thread 142984 that may be of use, as may the information and other attachments in the thread.

[ QUOTE ]
I found it difficult to join on the GDTXKY = F01131.ZZSERK.

Instead I had to hard code the join GDTXKY = 38494455

[/ QUOTE ]

Have you tried converting SERK to text first (missed this first time) and using a subquery in the select clause (this will NOT work for the column GDTXFT as it is a BLOB):

Example:

select zzserk,
(select GD???? from F00165 where GDOBNM = 'GT01131' and GDTXKY = TO_CHAR(ZZSERK))
from F01131
where ....

Another option could be an adaption of an Oracle database function procedure and view that Larry Jones posted some years ago. I adapted it for the data dictionary, but it could be used for the Work Centre. I don't know about adapting it to the AS/400 and DB2. (sorry Larry, I can't remember where your original post is and I don't have time to find it at the moment as I'm preparing a presentation for a conference)

Here is the database function procedure:

<font color="blue">
CREATE OR REPLACE FUNCTION dd811."JDETEXTFIX" (p_rowid in
ROWID) RETURN VARCHAR2
IS
v_textout VARCHAR2(4000);
v_lob BLOB;
v_buffer RAW(8192);
v_offset INTEGER := 1;
v_textlen BINARY_INTEGER := 8192;
v_rawlen NUMBER;
v_from_set RAW(2);
v_to_set RAW(1);
v_output RAW(8192);
BEGIN
SELECT gdtxft INTO v_lob
FROM DD811.F00165 where ROWID = p_rowid;
DBMS_LOB.READ (v_lob, v_textlen, v_offset,v_buffer);
v_textout := ' ';
v_from_set := HEXTORAW('7D00');
v_to_set := HEXTORAW('7D');
v_output := UTL_RAW.TRANSLATE (v_buffer, v_from_set, v_to_set);
v_rawlen := UTL_RAW.LENGTH (v_output);
if (v_rawlen > 4000) then
v_rawlen := 4000;
end if;
if (v_rawlen > 0) then
v_textout := UTL_RAW.CAST_TO_VARCHAR2 (UTL_RAW.SUBSTR(v_output,1,v_rawlen));
end if;
RETURN (v_textout);
EXCEPTION WHEN NO_DATA_FOUND THEN
RETURN (v_textout);
END;
</font>

Here is the database view that uses the funtion:

<font color="blue">
CREATE OR REPLACE VIEW dd811.F00165_VIEW AS
SELECT
GDOBNM,
GDTXKY,
GDMOSEQN,
GDGTMOTYPE,
GDLNGP,
GDUSER,
(CASE WHEN GDUPMJ > 0 THEN TO_CHAR(TO_DATE(TO_CHAR(GDUPMJ+1900000),'YYYYDDD'),'DD/MM/YYYY') ELSE '0' END) GDUPMJ,
GDTDAY,
GDGTITNM,
GDQUNAM,
GDGTFILENM,
JDETextFix(ROWID) GDTXFT
FROM DD811.F00165
WHERE GDGTMOTYPE = 0 WITH READ ONLY;
</font>
 
Thnaks Peter. Converting it to string did the trick. I couldn't convert to string on the AS400 green screen sql utility, but I had to do this using the ODBC drivers and Microsoft Reporting Services.

One of my colleagues attended your presentation and reckoned it was one of the better technical presentations at the conference.
 
I'm glad you got it working.

Thanks for the feedback on my presentation too.

The slide presentation is available on the web in PDF format from SlideShare, along with most, if not all, of the other presentations at InSync11 in Sydney, Australia.

The wed site is http://www.slideshare.net/InSync2011

You will have to signup to download any presentations, but signup is free.

I am happy to answer any questions and/or receive any comments on my presentation.
 
Hello,
Well, this topic is pretty old but it was useful as a starting point to extract data from the workcenter messages.
For some reason, I can only get the brief summary in F01131M. When I search in F00165 there is no matching GDTXKY. I tried a raw search in that table to see the most recent messages and I have not found mine. Is there any idea where it is stored then? When I go to JDE WC, it is displayed properly.
 
Hello,
Well, this topic is pretty old but it was useful as a starting point to extract data from the workcenter messages.
For some reason, I can only get the brief summary in F01131M. When I search in F00165 there is no matching GDTXKY. I tried a raw search in that table to see the most recent messages and I have not found mine. Is there any idea where it is stored then? When I go to JDE WC, it is displayed properly.
Hi Attila,

This thread is old! It was old when I first posted on it. That was 11 years ago. However I believe that the Work Center hasn't changed much over the years so the information in this thread, as well as other threads on JDEList and other sources of a similar age, is still valuable.

Please provide the details of how you searched the F00165 for the information you are after. I'll try and help you achieve your goal.
 
Hello Peter,
Indeed old, but the logic should be the same. So here is what i do:
SELECT ZZSERK, ZZSFRM, ZZMSGP, ZZTSV FROM F01131 WHEREE ZZUPMJ = 122365 AND ZZUSER = 'MYUSERNAME' FETCH FIRST 10 ROWS ONLY
This has the expected result:
ZZSERK​
ZZSFRM​
ZZMSGP​
ZZTSV​
22417139Batch processJob has completedR47011|VS47011|0|
Searching in F01131M also works:
SELECT ZMPSRK, ZMSERK, ZMMSGP, ZMLV WHERE ZMPPSRK = 2241739
Result:
ZMPSRK​
ZMSERK​
ZMMSGP​
ZMLV​
2241714022417142Error: ERROR - Customer Inhibited from B3
2241714022417141Warning: Pick date is less than todays d3
22417139224171402
Full text search in F00165 does not return a single row (I even removed the restriction for GDOBNM='GT01131')
SELECT * FROM F00165 WHERE TRIM(GDTXKY) IN ('22417139','22417140','22417141','22417142')
In my understanding the GDTXKY is the SERK from F01131 -> 22417139. But it is not there. Not even the SERK's from F01131M :confused:
 
Hi Attila,

Have a look at this SQL (which I posted on 12th August 2011):

select zzserk,
(select GD???? from F00165 where GDOBNM = 'GT01131' and GDTXKY = TO_CHAR(ZZSERK))
from F01131
where ....

Please note the TO_CHAR function (Oracle Database). This is needed. I can't remember why (I'm retired), but it is about the database character sets.

Adjusting your F00165 query to use the TO_CHAR function should give you what you need:

SELECT * FROM F00165 WHERE TRIM(GDTXKY) IN (TO_CHAR('22417139'),TO_CHAR('22417140'),TO_CHAR('22417141'),TO_CHAR('22417142'))
 
I did a little investigation into why the TO-CHAR function is needed. I believe the following is reasonably accurate. If it is not, hopefully a JDEList member, who knows this information better than me, can correct me.

JDE operates using the Unicode character set. So the database is set to Unicode. Literal values default to the NVARCHAR data type. Using the TO_CHAR function converts the literal to a VARCHAR data type. F00165.GDTXKY is a VARCHAR data type.
 
Hello Peter,

Thank you, but no joy, unfortunately :(
F01131-ZZSERK is a NUMERIC(15) field, whereas F00165-GDTXKY is CHAR(254), thus conversion from number to string is required for performance reasons.
Also, as I mentioned when I try to search in F00165 ordered by GDUPMJ and GDTDAY descending I can not find the entry either.
Let me ask somebody from the DBA team to clarify this, maybe there is a customization behind which redirects these to a custom table. I will get back to you if I know something more.
 
Hi Attila,

It is likely that your DBA team will be of limited assistance unless they have an understanding of how the JDE work centre functionality works.

A few questions. Does the information you are after from the F00165 appear in the JDE Work Center application? Which database are you using? What version of JDE are you using?

Assuming the information you are after from the F00165 does appear in the JDE Work Center application:

Try the SQL below.

SELECT *
FROM F00165
WHERE GDOBNM = 'GT01131'
AND ( TRIM(GDTXKY) IN (SELECT TO_CHAR(ZZSERK) FROM F01131 WHERE ZZUPMJ = 122365 AND ZZUSER = 'MYUSERNAME')
OR TRIM(GDTXKY) IN (SELECT TO_CHAR(ZMSERK) FROM F01131M WHERE ZMPPSRK IN (SELECT ZZSERK FROM F01131 WHERE ZZUPMJ = 122365 AND ZZUSER = 'MYUSERNAME'))
)

If this still does not return anything, get a debug log of the JDE Work Center application when you are accessing the details. Look in the debug log for an F00165 query.

Also the details and attachments in the "Work Center Report" thread below may help. It's old too.

https://www.jdelist.com/community/posts/131134/
 
Try the following:
SELECT * FROM LIBRARY/F01131M WHERE ZMPSRK in (
SELECT ZZSERK FROM LIBRARY/F01131
WHERE ZZUPMJ = Julian Date criteria
AND ZZTSV LIKE '%R47011%')

Not brilliant but it did the job for 1 of our users who wanted to see specific UBE errors. A few pointers though here:

1. WC messaging is next to useless imo if generic users are used for most processes, so you can use specific users for those processes which are of particular importance.
2. Custom processes should use custom built error management system (we built ours based on logging levels per process, so can control from UDCs)
3. Perform good housekeeping on WC tables - they tend to grow fast!

brgds
Andrew
 
Hello Peter,
I have not heard back from the DBA yet, unfortunately.
When I check the workcenter, the whole message is shown:
1672906379875.png
The query Andrew provided gives back what I already had - only the subject in F01131M ("Warning: Pick date is less than todays d").
Version is 9.2.5.2 anyway, database is DB2 on iSeries.
And as I mentioned, if I read F00165 ordered by date and time descending, I can not find the entry either.
More than confusing.
 
This is what I do in my WSJ WC message checking code

F01131 SERK links to F01131M PPSRK

Code:
00064  // Now get SERK from F01131 (use index on AN8 + SERK)
00065  // SERK is incremental so feeds into a chronological index by nature.
00066  //
00067 -F01131.Open
           
00068 -F01131.Select  [Index 3: AddressNumber, SerialNumber]
            BF mnAddressNumber [AN8] = TK Address Number [AN8]
            BF jdDateJobSubmitted [SBMDATE] = TK Date - Tickler [DTI]
            BF mnTimeJobSubmitted [SBMTIME] <= TK Time - Last Updated [UPMT]
            BF mnAddressNumber [AN8] = TK Address Number - Parent [PA8]
            VA evt_LevelIndented_LV [LV] = TK Level of Indention [LV]
            VA evt_TemplateSubstitValues_TSV [TSV] = TK Template Substitution Values [TSV]
00069 -F01131.FetchNext  [Index 3: AddressNumber, SerialNumber]
            BF mnKeyValueSerialNumber [SERK] <- TK Key Value Serial Number [SERK]
            BF szTemplateMessageID [TMPI] <- TK Template ID [TMPI]
00070  //
00071 -If SV File_IO_Status is equal to CO SUCCESS
00072  |   -F01131M.FetchSingle  [Index 2: ParentParent]
       |         BF mnKeyValueSerialNumber [SERK] = TK ParentKeyValueSerialNumberA [PPSRK]
00073  |   -If SV File_IO_Status is equal to CO SUCCESS
00074  |    |    BF cJobEndedinErrorY [EV01] = "Y"
00075  |    |    // FUTURE USE
00076  |    |    // Check to see if the WC message from F01131.ZZTMPI is in the list of errors
00077  |    |    // is in UDC 55 WC
00078  |    |    //
00079  |    End If
00080  End If
00081  //
00082 -F01131.Close
           
00083  //
 
Hello Peter,
I have not heard back from the DBA yet, unfortunately.
When I check the workcenter, the whole message is shown:
View attachment 19488
The query Andrew provided gives back what I already had - only the subject in F01131M ("Warning: Pick date is less than todays d").
Version is 9.2.5.2 anyway, database is DB2 on iSeries.
And as I mentioned, if I read F00165 ordered by date and time descending, I can not find the entry either.
More than confusing.

Hi Attila,

It is possible that the error information has not been stored in the F00165. I had a look at the information I posted in the "Work Center Report" thread I referred to in my previous post and did not actually find a reference to the F00165. It looks like, at lease in some instances, the error detail is built on the fly using the business function F01131GetBriefMessage.

You could look at the ER for the Work Center application to see how it produces the error detail.

Do you have R013151 - Message Center Print in your system? You could look at the ER for it to see how it produces the error detail.
 
Thanks everybody for helping me to achieve my goal here, I think I finally found what I need. As I am not a JDE expert nor I have the necessary authorization, I had to find a solution which work on pure SQL. This post and Peter's advice on F01131GetBriefMessage helped me a lot to understand what might happen in the background. I think the error described there is not even an error, but rather a feature. A useful feature.
So when I extract the information from F01131M, we have a column called ZMTMPI which is a foreign key to F00165. But in this case it is a system error, so the text itself is not stored, I have to do a lookup with F00165.GDOBNM = 'GT92002' AND F01131M.ZMTMPI = F00165.GDTXKY||'|||'
There are three pipes at the end, as I am looking for the english text - for localization it can be extended with for example F00165.GXTXKY||'|F||' to have the french translation if required (depends on client setup).
One more important thing, for me the F00165 in the production database did not contain these error messages, seems they are split - custom messages are stored there, but standard ones are in a different one. If you are about to find yours, you can use the following query to list out the databases which have a table named F00165:
SELECT TABLE_SCHEMA FROM QSYS2.SYSTABLESTAT WHERE TABLE_NAME='F00165'
Then you can check content-wise whether you can find an entry there where GDTXKY LIKE ZMTMPI%

So, all in all, here is a query to print out the last status of an EDOC with english error description:
SELECT DATE(CHAR(ZZUPMJ+1900000)) AS PROCESS_DATE,SUBSTR(LPAD(ZZUPMT,6,'0'),1,2) ||':'||SUBSTR(LPAD(ZZUPMT,6,'0'),3,2) ||':'||RIGHT(ZZUPMT,2) AS PROCESS_TIME,ZZUSER AS USERNAME,GDTXFT AS ERROR_DETAILS FROM F01131M AS M
LEFT JOIN F01131 AS F ON M.ZMPPSRK = F.ZZSERK
LEFT JOIN YOURLIBRARY.F00165 AS D ON D.GDOBNM='GT92002' AND GDTXKY= TRIM(ZMTMPI)||'|||'
WHERE ZMPPSRK IN (SELECT MAX(ZMPSRK) FROM F01131M WHERE ZMTSV='YOUR_EDOC_GOES_HERE')
And the result is:
PROCESS_DATE​
PROCESS_TIME​
USERNAME​
ERROR_DETAILS​
2023-01-0309:57:37JOHNDOECause . . . . . Order &1 contains errors. Resolution. . Review the detail errors for Order &1 .
2023-01-0309:57:37JOHNDOECause . . . . . The customer is inhibited from batch processing. Resolution. . . Go to Billing Instructions and change the Batch Processing Mode for this customer, or use a different customer.
As of now this is enough for me, as I know the error detail has placeholder(s) which can be put back from ZMTSV, actually it is the EDOC itself, but when there is more they are separated with pipes.
There is one thing I still miss, it is the subject. ZMMSGP in F01131M has a truncated version, so it is stored somewhere else, most probably also referenced by a foreign key but I have not found it yet.
 
Back
Top