KMTree.par
La librería que el otro día construimos se queda absolutamente corta… La funcionalidad que ofrece es mínima y no me pareció suficiente como para construir el explorador que me han encargado desarrollar. Por ello, me volví a sumergir en el SDN y encontré un desarrollo que genera un árbol de exploración del KM: Justo lo que buscaba.
Aquí te proporciono un enlace a la página original, el .PAR compilado, las librerías necesarias para hacerlo y una lista de las mismas. En breve se actualizará este post con mi versión final que implementará las diferencias exigidas por mi cliente en particular.
La lista de includes es:
- bc.rf.framework_api.jar
- bc.util.public_api.jar
- com.sap.portal.htmlb_api.jar
- com.sap.security.api.ep5.jar
- htmlb.jar
KMTree.par (Recuerda sustituir la extensión JPG por RAR)
KMLibrary.jar
Estoy inmerso en el desarrollo de una aplicación que básicamente es un explorador de ficheros para el portal. En un principio se barajó el poner dichos ficheros en un servidor web a pelo, pero pronto aprendí que por motivos de seguridad, Apache y en general los servidores web, por motivos de seguridad, no atienden peticiones de Java, por lo que mi componente Java no podía explorar el directorio de dicha forma. El siguiente paso fue estudiar la posibilidad de FTP; este caso es perfectamente viable, siempre que tu cliente (Me refiero al que paga los garbanzos) no sea el mío. En ese caso, puedes usar la librería de Enterprise Distributed Technologies para realizar tus desarrollos.
El caso es que mi cliente no acepta la “inseguridad” de un FTP, así que lo siguiente que se planteó fue usar el KM directamente… Pero no les gusta la presentación que éste hace de la lista de ficheros, por lo que me veo en la necesidad de desarrollar un componente Java que explore el KM y lo presente a gusto del mecenas de turno. Para ello, encontré en el SDN (Tienes todos los enlaces que puedas estar deseando al final del post) el código de una librería para este propósito: El manejo del KM.
Me costó bastante encontrar los .JAR necesarios para cumplir los includes. A continuación te paso una lista de los mismos. Así mismo, te pongo un enlace a un fichero llamado KMLibraryrar.jpg al que deberás quitar la extensión JPG y sustituirla por RAR. En el paquete resultante tienes la librería compilada y los .JAR necesarios para su compilación/recompilación. La lista es la siguiente:
_webdynpro_progmodel.jar
bc.rf.framework_api.jar
bc.util.public_api.jar
com.sap.security.api.ep5.jar (Con Deprecated Warnings)
com.sap.security.core.ep5.jar (Con Deprecated Warnings)
webdynpro_services.jar
Las librerías con “Deprecated Warnings”, posiblemente tendrán alternativas más adecuadas que eliminen estos warnings… Este post será editado en caso de encontrar tales librerías. Si alguno de vosotros encuentra dichas alternativas, por favor, que me lo haga saber.
———
KMLibrary (Source / KMLibraryrar.jpg)
Otros enlaces de interés y ejemplos:
Enterprise Distributed Technologies (FTP Library / API)
http://www.jscape.com/articles/simple_ftp_using_java.html
http://forums.sun.com/thread.jspa?messageID=4332595
http://www.jajakarta.org/…/net/FTP.FTPDirectoryScanner.html
http://www.example-code.com/java/ftp_listDirectory.asp
http://www.javapractices.com/topic/TopicAction.do?Id=68
http://www.anddev.org/generalized_file_manager_2_-_gfm20-t397.html
Añadir un campo a una iView Standard
Lo haremos a través de la BAdI HRPAD00INFTYUI y la personalización de iViews que el portal nos permite.
1) Primero crearemos una implementación para la BAdI. Lo haremos a través de la SE19 en “Create Implementation”, “New BAdI”. Introduciremos el nombre de la BAdI que queremos implementar, en este caso: “HRPAD00INFTYUI”.
En el siguiente paso daremos un nombre a la implementación (ej: ZLINX_HRPAD00INFTYUI) y una descripción.
A continuación rellenaremos el siguiente formulario. En la primera casilla, introduciremos un nombre para la implementación de la BAdI, distinto al anterior y que no usaremos en adelante (ej: ZLINX_BADI_ESS); en la segunda casilla, introduciremos un nombre para la clase de la implementación (ej: Z_CL_EX_HRPAD00INFTYUI); en la tercera casilla, por último, seleccionaremos el nombre de la BAdI que queremos implementar (ej: HRPAD00INFTYUI).
Con esto ya tenemos creada la implementación y podemos desarrollar los métodos que nos hagan falta. Para nuestro propósito, desarrollaremos el método IF_EX_HRPAD00INFTYUI~INPUT_CONVERSION.
Pero dejemos esto a un lado un segundo.
2) Debemos tener claro qué estructura queremos/debemos modificar. Para ello, podemos usar varios métodos; en mi caso, para estar perféctamente seguros de qué estructura se usaba, implementamos un código en el método antes creado, que tomaba el nombre de la estructura y lo guardaba en una tabla. Seguro que a desarrolladores más expertos se les ocurrirán mejores maneras o lo podrán leer sin problemas de la parametrización del sistema… Pero yo propongo un código similar a este:
METHOD if_ex_hrpad00inftyui~input_conversion.
DATA wa_log TYPE zhr_xss_log.
CASE screen_structure_name.
WHEN ‘HCMT_BSP_PA_PREF’.
MOVE-CORRESPONDING screen_structure TO pref.
WHEN OTHERS.
ASSIGN screen_structure TO <screen_structure_0021>.
wa_log-caseval = screen_structure_name.
INSERT into zhr_xss_log values wa_log.
ENDCASE.
IF pnnnn2 IS REQUESTED.
MOVE-CORRESPONDING screen_structure TO pnnnn2.
ENDIF.
ENDMETHOD.
De esta forma obtendremos tras la ejecución de nuestro iView, el nombre de la estructura utilizada, como una entrada en la tabla que hemos creado para este fin. De esta forma, sabremos que, por ejemplo, necesitamos modificar la estructura “HCMT_BSP_PA_CH_R0021″.
3) Nos dirigimos a la estructura “HCMT_BSP_PA_CH_R0021″, en nuestro ejemplo, y lo que hacemos es ampliarla con los campos nuevos que queramos mostrar en el espacio para usuario reservado por SAP en la estructura. Una vez hecha esta ampliación, es imprescindible reiniciar el portal.
4) Con un usuario administrador, nos dirigimos al portal, y volvemos a lanzar la preview del iView. Si el iView se compone de varias pantallas, tendremos que usar la técnica de CTRL+RIGHT_CLICK en todas ellas. Con esta combinación aplicada sobre un campo del iView, accederemos a un panel de personalización de los campos. Pulsando sobre el contenedor, veremos un enlace llamado “Edit Custom Extension Fields“, dentro del cual, pordremos hacer visibles nuestros nuevos campos y realizar alguna personalización sobre los textos, por ejemplo.
5) Volvemos a nuestro método “input_conversion” y nos disponemos a introducir el código que definitivamente capturará nuestros nuevos campos para ser insertados en el Infotipo correspondiente. Como ejemplo, podemos ver este código.
METHOD if_ex_hrpad00inftyui~input_conversion.
DATA wa_log TYPE zhr_xss_log.
CASE screen_structure_name.
WHEN ‘HCMT_BSP_PA_PREF’.
MOVE-CORRESPONDING screen_structure TO pref.
WHEN ‘HCMT_BSP_PA_CH_R0021′.
FIELD-SYMBOLS: <screen_structure_0021> TYPE hcmt_bsp_pa_ch_r0021,
<p0021> TYPE p0021.
ASSIGN: pnnnn TO <p0021> CASTING,
screen_structure TO <screen_structure_0021>.
MOVE-CORRESPONDING screen_structure TO pnnnn.
MOVE <screen_structure_0021>-z_fasin TO <p0021>-fasin.
ENDCASE.
IF pnnnn2 IS REQUESTED.
MOVE-CORRESPONDING screen_structure TO pnnnn2.
ENDIF.
ENDMETHOD.
Siendo Z_FASIN el campo que introdujimos previamente en la estructura.
Si hemos dado todos los pasos de forma correcta, tendremos como resultado nuestro iView ampliado con los campos que deseemos, de tal forma que la información que el usuario introduzca, será guardada en el Infotipo adecuado.
———
Bibliografía:
SAP: iView de exploración de KM externo
1) Creamos un nuevo iView del tipo predeterminado “URL iView”.
2) En la URL introducir el siguiente path, que apunta al KM de destino:
“https://portal.<DOMINIO>.com/irj/go/km/prteventname/HtmlbEvent/prtroot/pcd
!3aportal_content!2fevery_user!2fgeneral!2feu_role!2fcom.sap.km.home_ws
!2fcom.sap.km.hidden!2fcom.sap.km.urlaccess!2fcom.sap.km.Navigation/
<RUTA_DESEADA_EN_EL_KM>“
3) Una vez ya creado, editar el objeto y añadir el siguiente parámetro por método GET: StartUrl=/<RUTA_DESEADA_EN_EL_KM>
SAP: Transacciones del R3
A continuación detallo una lista de las transacciones que más he utilizado y por tanto, las que egoistamente considero más importantes y dignas de recordar o, en este caso, tener apuntadas. El sistema de nombres de las transacciones no está hecho para una mala cabeza como la mía.
SE09: Liberar Ordenes de Transporte.
SE10: Liberar Ordenes de Transporte.
SE11: Diccionario de Datos.
SE16: Visualizar el contenido de tablas.
SE16n: Modificar el contenido de tablas.
SE19: Gestión de BAdIs.
SE37: Gestión de Funciones / Módulos de Función.
SE41: Gestión de “Status”.
SE36: BBDD Lógicas.
SE38: Editor ABAP.
SE51: Screen Painter.
SE54: Gestión de tablas gerarquizadas / Clusters de Vistas.
SE63: Entorno de Traducción.
SE80: Creación de Grupos de Funciones / ModulPool.
SE91: Gestión de Mensajes de Sistema.
SE93: Creación de Transacciones.
SM12: Visualizador de Bloqueos.
SM30: Vistas de Actualización.
SM34: Visualizar / Usar Clusters de Vistas.
SM36: Creación de Jobs.
SM37: Visualización de Jobs.
SU01: Gestión de Autorizaciones.
SU01d: Visualización de Autorizacioines.
SU21: Gestión de Objetos de Autorización.
SU53: Checkea Autorizaciones para una Tarea.
PB03: Medidas de Organiación.
PB20: Visualizar Datos de Candidatos.
PB30: Actualizar Datos de Candidatos.
PB40: Medidas de Candidatos.
PA42: Medidas de Entrada Rápida.
PA70: Infotipos de Entrada Rápida.
PFCG: Gestión de roles.
PP01: Actualizar Objeto.
PM01: Gestión de Infotipos (Creación).
PPOSE: Explorar Unidad Organizativa.
SHDB: Grabación para Programas de Carga.
SPRO: IMG del sistema (Config/Parametrización).
SFP: Adobe Form Builder.
ST01: Trazas.
STMS: Transportar.
