Contributor.
Contributor.
67 views

SAP custom infotypes

I have been having a little bit of fun with my least favourite driver, trying to help a customer who wants to add a custom infotype to their position objects in SAP HR.

Some years ago we extended an existing infotype for users (0032), adding some control flags in SAP that could be used to determine if a user needed a full network account (and email) and if they needed access to SAP finance as a user. That worked fine, but the SAP guy who set it up has long gone and the record of what was done is scant.
I do know that I had to add the extra details into the correct segment of the HRMD_A5 file and add a schema mapping etc.
For positions the customer has added a custom infotype 9005 and we are getting that out as an iDoc, but for some reason, the Remote Loader and shim is using an offset when reading the BEGDA and ENDDA and reading them in the wrong order - resulting in all my iDocs being turned into future events.

The line in an iDoc for the working 0032 extension looks like this, (where the pipe symbol is the 63 character offset):
Z2P0032000 ... |000252410032 999912312019041000020200226 ... NY

the corresponding schema information is
SEGMENT:P0032:E1P0032:
P0032:PERNR:0:8
P0032:INFTY:8:4
P0032:SUBTY:12:4
P0032:OBJPS:16:2
P0032:SPRPS:18:1
P0032:ENDDA:19:8
P0032:BEGDA:27:8
...
P0032:NETU:325:1
P0032:SAPU:326:1

so we have ENDDA at point 19, followed by BEGDA at 27

For posiiton, the iDOc line is:
Z2P9005000 ... |32001S 50007314 12020022699991231 0009005 ... 001

the schema is
SEGMENT:P9005:E1P9005:
P9005:MANDT:0:3
P9005:PLVAR:3:2
P9005:OTYPE:5:2
P9005:OBJID:7:8
P9005:AAAAA:15:5
P9005:BEGDA:20:8
P9005:ENDDA:28:8
...
P9005:STLEV:94:3

It must be working after a fashion, because I can see in my RL trace that it does correctly find the STLEV value that I want from the iDOc, but it seems to ignore my definition of BEGDA and ENDDA and defaults to the same as for most other segments (as for 0032), so sees the BEGDA as 69999123 and treats it as a future (very future) event. Is there a standard place in an iDoc where the BEGDA and ENDDA must go - I assumed it would be as defined in the schema file.

The working iDoc puts this in the RL trace:
DirXML: [02/26/20 14:20:48.21]: TRACE: ParseIDoc: No Character Set Encoding specified. Using default encoding: UTF8
DirXML: [02/26/20 14:20:48.21]: TRACE: ParseIDoc: IDoc file opened successfully.
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: IDoc to parse: /usr/sap/GED/SYS/global/saphridmconnector/O_320_0000000000057056
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Segment EDI_DC40
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Segment E2PLOGI
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Object type P found in filter.
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Parsing object type P segment
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Object identifier: 00025241
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Operation: U
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: E2PITYP found
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Parsing infotype: 0032, subtype:
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: GSA segment 'Z2P0032000'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Infotype 'P0032' is in filter or valid
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field name: 'P:P0032:KFZKZ:none'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: keyVal is 110:20
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is at location 110, length 20
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: IDOCOFFSET: '173', len: '20'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is: ''
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Infotype 'P0032' is in filter or valid
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field name: 'P:P0032:SAPUSER:none'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: keyVal is 326:1
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is at location 326, length 1
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: IDOCOFFSET: '389', len: '1'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is: 'Y'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Putting field 'P0032:SAPUSER:none:326:1', value 'Y' in inputHash hashtable
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Infotype 'P0032' is in filter or valid
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field name: 'P:P0032:NETWORK:none'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: keyVal is 325:1
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is at location 325, length 1
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: IDOCOFFSET: '388', len: '1'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Field data is: 'N'
DirXML: [02/26/20 14:20:48.22]: TRACE: ParseIDoc: Putting field 'P0032:NETWORK:none:325:1', value 'N' in inputHash hashtable
...
<modify-attr attr-name="P0032:SAPUSER:none:326:1">
<remove-all-values/>
<add-value>
<value seqnr="000" timestamp="20190410-99991231">Y</value>
</add-value>
</modify-attr>

The failing iDoc has:
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: IDoc file opened successfully.
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: IDoc to parse: /usr/sap/GED/SYS/global/saphridmconnector/O_320_0000000000057058
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Segment EDI_DC40
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Segment E2PLOGI
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Object type S found in filter.
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Parsing object type S segment
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Object identifier: 50007314
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Operation: U
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: E2PITYP found
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Parsing infotype: 9005, subtype:
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: GSA segment 'Z2P9005000'
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Writing future dated segment type 'P9005'
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Setting earliest future date from 0 to 69999123
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Infotype 'P9005' is in filter or valid
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Field name: 'S:P9005:STLEV:none'
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: keyVal is 94:3
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Field data is at location 94, length 3
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: IDOCOFFSET: '157', len: '3'
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Field data is: '1'
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Putting field 'P9005:STLEV:none:94:3', value '1' in inputHash hashtable
DirXML: [02/26/20 15:00:45.11]: TRACE: ParseIDoc: Earliest future date was '69999123'
...
<modify-attr attr-name="P9005:STLEV:none:94:3">
<remove-all-values/>
<add-value>
<value seqnr="1 " timestamp="69999123-12020022">1</value>
</add-value>
</modify-attr>

So not only do I end up with a futr iDoc I also get garbage sent through to the driver.

There seems to be very little good documentation on this stuff, so any pointers would be appreciated

Labels (1)
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.