My friend and Mentor gregorw posted recently on setting up Linux print services with a modern SAP install base ( https://blogs.sap.com/2017/06/25/setup-a-hp-color-laser-jet-on-the-sap-netweaver-as-abap-developer-e... ). As I will be presenting on an enterprise output management consolidation project at the 2018 ASUG conference, I wanted to share experiences with the other side of the developer view Gregor has. He's on the front of the curve, and I'm on the back end, tidying up stray bits of decades of SAP setups.
This isn't a how-to as much as a few what-fors, because each external management solution will vary. What won't change much in the HANA world is the Linux application server model. Having UNIX and Linux backgrounds might help get system components working. Or there may be hidden aspects that a single-user administrator of an "own system" may not have managed before.
Previously:
Gregor had to deal with setting up OS level printing services, and maybe some OS printer device configuration. Not easy, but maybe not easily scalable if the printers vary by manufacturer, type, paper size, special forms, etc. That burden moves to the enterprise application, lessening specialized work done on the Linux app servers.
Security is applied via standard transactions, if needed, in the SAP system for external management access to update spool status (user feedback and error reporting).
The external management system is configured by imports (not transports) in the SPAD transaction suite. Test until things match.
OMS import snippet (ROMS and LOMS...)
The above text entries should load into the SPAD OMS transactions for operations such as submit, cancel, query, etc.
We found a small path issue with the UNIX "echo" command so added the full path (best practice anyway to avoid wrong results).
The usual SAP spool processes are defined and checked.
Pushing the required code to the application server is a one-time process, and the UNIX/Linux versions we deployed lend themselves to simple network distribution.
Post install testing of the executable is a snap at the OS level:
Doing this verifies issues printing from SAP are not caused by missing OS pieces. One nice feature of the solution we are using is the only OS level install is a command line executable (with supporting libraries) that does not need to run as a service, start on boot, or be managed dynamically.
In related testing, I created an image file in HP PCL (printer control language) format, as many SAP spool requests were being created as PCL streams,
The user and group IDs needed for the application are typically deployed as root, but we tested and push out as non-root users and have seen no side effects,
The application that queues SAP spool requests may need firewall rule access to the output management servers, depending on which domains each run. We've not seen issues from systems hosted in different zones/cloud spaces.
The SAP identity needed to report output request status back to the SAP system is maintained in the output management system, not the application server or the SAP stack other than the security profiles noted above.
You could use transaction RSPOXDEV to move printer definitions from legacy non-HANA SAP systems into an SAP HANA system. I'd be selective here; no reason to pull in dead queues!
This isn't a how-to as much as a few what-fors, because each external management solution will vary. What won't change much in the HANA world is the Linux application server model. Having UNIX and Linux backgrounds might help get system components working. Or there may be hidden aspects that a single-user administrator of an "own system" may not have managed before.
Previously:
- https://blogs.sap.com/2016/09/30/i-carry-a-spool-or-how-the-abap-detective-found-his-lp/
- https://blogs.sap.com/2017/04/12/the-abap-detective-presses-on/
Gregor had to deal with setting up OS level printing services, and maybe some OS printer device configuration. Not easy, but maybe not easily scalable if the printers vary by manufacturer, type, paper size, special forms, etc. That burden moves to the enterprise application, lessening specialized work done on the Linux app servers.
Security is applied via standard transactions, if needed, in the SAP system for external management access to update spool status (user feedback and error reporting).
The external management system is configured by imports (not transports) in the SPAD transaction suite. Test until things match.
OMS import snippet (ROMS and LOMS...)
VERSION = "0.1"
TIME = "20170405150935"
SYSTEM = "SAP"
RELEASE = "701"
* ROMS = {
[...]
}
* LOMS = {
* COMMAND = {
OPSYS = "AIX"
[...]
* COMMAND = {
OPSYS = "Linux"
LCMD = "PATH"
CMD = "/opt/lrs/lrsq/"
}
* COMMAND = {
OPSYS = "Linux"
LCMD = "SUBMIT"
CMD = "lrsq /SAPU:""&P,&EI,&EG,&Es,&ES,&o,'&T',&S,&L,&C,&Y,0,0,&R,&D"" &E4 /file:&F /Que:&P /sep:&H/S/N/"
}
[...[
CMD = "nlrsq.exe /SAP:""&P,&EI,&EG,&Es,&ES,&o,'&T',&S,&L,&C,&Y,0,0,&R,&D"" &E4 /file:&F /Que:&P /sep:&H/S/N/"
}
}
The above text entries should load into the SPAD OMS transactions for operations such as submit, cancel, query, etc.
We found a small path issue with the UNIX "echo" command so added the full path (best practice anyway to avoid wrong results).
The usual SAP spool processes are defined and checked.
**** ERROR file opened at 20170917 112001 Eastern Daylight Time,
SAP-REL 720,0,720 RFC-VER 3 1567317 MT-SLT:18464
Error in program 'nvpsx': ======>
SAP_CMINIT3 : rc=20 >
Connect to SAP gateway failed
Connect_PM GWHOST=[], GWSERV=[], SYSNR=[]
unsupported os or bad lib path:
/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Pushing the required code to the application server is a one-time process, and the UNIX/Linux versions we deployed lend themselves to simple network distribution.
Current OS release (Linux 3.0.101-0.47.52-default) is fully supportedPost install testing of the executable is a snap at the OS level:
./lrsq /S:outhost /p:0000 /Que:PRT-MFD-101 /File:readme
Tracking Id: PRT-MFD-101:00000012
Print File (readme) processed successfully.Doing this verifies issues printing from SAP are not caused by missing OS pieces. One nice feature of the solution we are using is the only OS level install is a command line executable (with supporting libraries) that does not need to run as a service, start on boot, or be managed dynamically.
In related testing, I created an image file in HP PCL (printer control language) format, as many SAP spool requests were being created as PCL streams,
The user and group IDs needed for the application are typically deployed as root, but we tested and push out as non-root users and have seen no side effects,
# chown lp:lp *The application that queues SAP spool requests may need firewall rule access to the output management servers, depending on which domains each run. We've not seen issues from systems hosted in different zones/cloud spaces.
The SAP identity needed to report output request status back to the SAP system is maintained in the output management system, not the application server or the SAP stack other than the security profiles noted above.
You could use transaction RSPOXDEV to move printer definitions from legacy non-HANA SAP systems into an SAP HANA system. I'd be selective here; no reason to pull in dead queues!
- SAP Managed Tags:
2 Comments
