Deseo conocer las principales diferencias entre Abap y Abap-HCM.
¿Quisiera saber si es requerido saber Abap antes de iniciar Abap-HCM?
¿Que temas se consideran necesarios para aprender Abap-HCM?
No tengo experiencia en abap ni abap hcm.
El "Code Inspector" verifica el rendimiento, la seguridad, la posibilidad de espera, la propensión a cometer errores y la información estadística de objetos individuales o conjuntos de objetos (programas, grupos de funciones, clases, interfaces, objetos DDIC).
El "Code Inspector" puede llamarse directamente desde el editor ABAP (SE38), el Function Builder (SE37) y el generador de clases (SE24) para los objetos individuales correspondientes (Objeto->Verificar->Code Inspector). A continuación, la verificación se realiza con una variante de verificación DEFAULT.
De ahí, cuando lancemos la transacción correspondiente al programa, el break debería saltar correctamente en productivo, sin necesidad de haber pasado ninguna orden de transporte.
Este aporte increíble pertenece al usuario "E_Hinojosa" del foro oficial de SAP, quien compartió su conocimiento aquí.
Saludos,
SapBlogger desde Consultoría-SAP
1. Motivation
The user breakpoint in ABAP helps you to debug the ABAP components of applications, that use RFC- and HTTP- based communications. These could be Web Dynpro applications, BSP's, ABAP-based web services, RFC-enabled function modules and so on. By setting a user breakpoint you can interrupt the processing of external HTTP or RFC requests in your ABAP backend system and debug them.
You can set a user breakpoint in the Object Navigator (transaction SE80) or the ABAP Editor (transaction SE38). Before you set a user breakpoint you may want to specify the user to whom the breakpoint applies. By default your user is set. You can enter the user in the User field of the debugging settings dialog (Utilities->Settings->Debugging). Before you start debugging, make sure that you use the New ABAP Debugger (select the checkbox New Debugger ). Now HTTP or RFC requests can be sent to your ABAP backend system - you are ready to capture them for debugging.
En muchas ocasiones, las ayudas de busqueda estandar de Sap (Matchcode), a las que accedemos como ayuda para completar los valores de los campos pulsando la tecla de función F4, son insuficientes para nuestras necesidades o no tienen en cuenta cosas tan obvias como no incluir registros que tienen peticiones de borrado.
Para estas ocasiones, tenemos la posibilidad de definir nuestras propias ayudas de búsqueda (Z) e incluirlas como una ayuda adicional en las ayudas estandar. Las ayudas estandar suelen ser ayudas complejas que incluyen varias ayudas simples, que podemos ir seleccionando según nuestras necesidades (en la imagen, podeís ver las ayudas de búsqueda disponibles cuando estamos dando de alta datos maestros de cliente a través de la transacción XD01).
Como ejemplos de ayudas de búsqueda que habitualmente se van a tener que definir en el sistema, tenemos:
- Administración de personal: búsqueda por el segundo apellido, ya que es muy frecuente empleados con los mismos apellidos, y este tipo de búsqueda no esta incluido en el estandar.
- Datos maestros: ayudas de búsqueda que excluyan registros con petición de borrado. Esto puede aplicar a proveedores, clientes, materiales, etc.
- Busqueda por otros criterios: en muchas ocasiones nos puede interesar buscar por otros criterios que no son estandar, campos de cliente u otros campos estandar que andan perdidos en los datos maestros pero por los que nos interesa realizar búsquedas.
- Ayudas personalizadas: también podremos incluir ayudas que ataquen a tablas Z o a vistas de datos estandar y tablas de cliente. Por ejemplo, en un sistema con control de imputaciones por cuentas contables, incluir una ayuda de búsqueda que nos indique, por cuenta contable, donde podemos imputar (tirando de tablas de cliente).
SWUD is the diagnosis transaction. This will guide you through the fault finding process. The check-list order is determined dynamically according to:
The testbed, provides a launchpad for tests to ensure that your workflow definition is rugged enough for the production environment. It also allows you to access the tasks, subflows, object types, delegated object types and agent assignments directly, without going through the workflow builder first. (Foreground tasks with no agent assignment are marked in red from release 4.5 onwards). This list is also useful as a catalogue of the components of workflow for documentation or transport purposes.
Click on the "info" icon to read a description of the test being performed.
Any workflow accessed through this transaction is added to the last-used list. The workflow can be recalled at a later date by clicking on the reuse icon in the left-hand column of the last-used list.
The workflow can be recalled at a later date by clicking on the reuse icon in the left-hand column of the last-used list.
The next section describes the transactions called from SWUD. Experts may find it easier calling them directly.
Secondary Diagnosis Transactions -
Transaction SWU3: Verify Workflow Customizing.
In this transaction the most important basic customizing for workflow is checked. If you find any errors here, read the documentation for the error. If your system is BBP or CRM, see note 60801.
- Transaction SWEL: Event Log.
Note: Before you can use the event log, you must make sure it is activated. You check this in transaction SWELS. If you are not sure whether or not it is active, just deactivate and activate the event log once.
WARNING: An activated event log can lead to bad performance, and must not be activated constantly in a productive system.
- Transaction SWE2: Event type linkage
A workflow is usually started or triggered by an EVENT so it is important to make sure that an event occurrs. In the event log you can see the event and its business object type. If an event has been successfully created, it is important to check if there is a receiver type for this event. The receiver type is the workflow that has been triggered by the event. The coupling between an event and the receiver can be maintained in trans. SWE2.
- Transaction SWU0: Event simulation
If you have found NO receiver type in the event log, then you should check transaction SWU0, Simulate Events. In this transaction you can simulate an event. The system will check all workflows that could be triggered by the event and tells you whether or not they were triggered. Information is displayed for the workflows that were not triggered successfully.
- Transaction SWI1: Work item list
If a workflow was been correctly triggered and started at least one WORK ITEM should be created. You can view the work items in transaction SWI1, Work Item Selection. The easiest way for the selection is just to go into this transaction after you have checked the event log. By default all the work items of the last hour will be displayed. You will find in this transaction the work item number, the status of the work item and the workflow task that has created the work item. Furthermore, (in the technical workitem display) you can have a look at the container by selecting a work item and using the menu GOTO -> CONTAINER. To display the work item details double click on the item. From the details you can see the selected/ possible/excluded agents for this work item by using the menu GOTO -> AGENT -> SELECTED/POSSIBLE/EXCLUDED AGENTS.
When the status of the work item shows an error you should have a look at the workflow log using the menu EDIT -> DISPLAY WORKFLOW LOG. Here you can see errors that have occurred.
- Transaction PFTC/SWDD: Task editor/Workflow Builder
If you want to have a look at the definition of the workflow you can use transaction PFTC, Maintain Tasks. The button WORKFLOW BUILDER brings you to a graphical display of the workflow structure which is fairly easy to read and understand. On the tabstrip TRIGGERING EVENTS you can check if the triggering is activated or not and deactivate/activate it by clicking on the icon in front of the event.
- Transaction OOCU: Customizing overview
To check if the relevant tasks are activated and users are assigned, you can use transaction OOCU; Task Customizing Overview. In this transaction all the tasks are sorted by the application components and are thus easy to find. Note that if you have almost no entries in this transaction, you should execute the report RS_APPL_REFRESH in transaction SE38.
- Transaction SWUE/SWUS: Event/workflow trigger
If you have activated a user exit, e.g. for the role determination, and you have problems with that, you most probably have to debug the workflow. This can be done using the transaction SWUS or SWUE.
With SWUE you can create an event. After you entered object type and event you have to fill the event parameters and the key for a specific object. If you want to debug the workflow you have to set the flag TRIGGER RECIEVER FM SYNCHR. If you have set a break point in your user exit or in any other function module of the workflow the system will stop at this break point and you can start analyzing.
The second possibility to debug a workflow is to use the transaction SWUS, the workflow test environment. In this transaction you have to enter the workflow task and fill the input data. Please use the F4-help to fill the input data. Here again you have to set a break point in your user exit or in any other function module of the workflow and then the system will stop there.
Summary of the manual alternative to SWUD
Now that you have a better understanding of how to use these transactions, you can follow the steps below to quickly analyze your workflow problems:
1. Go to transaction SWU3 and check if everything is okay. If it is not, please fix it before you proceed.
2. Go to transaction SWEL and check if an event is created. If not, check in transaction SWELS if the event log is activated.
- If you see an event but no workflow is triggered, proceed with step 3.
- If you see an event and a workflow is triggered, but the status of the triggering shows an error, proceed with step 3.
- If you see an event and a workflow is triggered and there is no error, proceed with step 4.
- If the event log is activated and you do not get any event, open up a message using the component of the application to which the business object type belongs. From release 20C for creation of shopping carts the architecture of workflows changed and no events are visible!
3. Go to transaction SWU0 and simulate the event. Is the workflow that you expect to be triggered visible in the simulation?
- If it is not, then check the workflow definition in PFTC. The event must be defined as triggering event.
- If it is, but the event linkage is not activated, go to transaction OOCU and activated it.
- If it is visible, but it is not activated, go to transaction PFTC and activate it.
4. Go to transaction SWI1. Search for the work item that belongs to the workflow. Check the status of the work item.
Reblogged from SDN.sap.com
