In the new Visual Studio 2022 plugin, it is not possible to create script files (or perform other BO operations) without first checking out and making a dummy edit to any custom BO.
I had created a custom BO yesterday and wanted to proceed with the script files today, when I noticed that I couldn't create them:
The following is the process for installing SAP Cloud Application Studio via the "Visual Studio 2022 plugin" avenue:
When you go to SE91 and want to translate messages, the system will generally only display the message you selected for translation.
If you want to handle the translation more efficient, go to SE63, select transport object, enter R3TR MSAG and the name of your message class, specify source and target language and click edit.
In the next screen, all your messages are displayed. Click "Sequentially Process Objects" and you can edit one message after another, pressing F7 and F8 to navigate back and forth.
Some background information recently obtained via an SAP incident regarding the finalize logic (finalize means that BeforeSave is triggered):
In case you're facing a C4C dump (500 Internal Server Error), create an incident from it and find that the the Incident Context => /SAP/ABAP/RuntimeError file shows the error "Object instance creation of action rejection implementation class "<PDI solution namespace>_CL_ACTION_VALIDATION" of action "<PDI solution namespace>_<ID>" on node "ROOT" in BO "<BO>" failed" - you have to do a full solution activation to resolve the issue.
If you want to add an extension field to the standard c4codatapi service via Cloud Application Studio, you will find that "c4codataapi" is not listed in the ODATA dropdown when you create the ODATA Extension (.xodata) object.
As C4C development systems (that are in development) use a different namespace than non-dev systems, simply copying or transporting an iflow from DEV to TEST (or PROD) will lose all extension field mappings.
You can either adjust your iflows manually. This involves uploading the test system WSDL to the iflow and re-mapping all extension fields from the DEV namespace to the test/production namespace, which is not recommended as it is very error-prone.
However, you can also do this automatically with a one-line change as follows:
The C4C object identifier webservice (CommunicationServicesManagementQueryObjectIdentifierMappingIn/Query Object Identifier Mappings) only works if you supply the correct Remote and Local ID type code. Thankfully, the documentation (linked above) provides a list of type codes for commonly used objects, however, the employee business object is missing.
To make it short, the type codes for employee are:
I recently needed to modify the body of an HTTP response in a BSP page. Previously, the request was simply returning a status 403. This was done using request->set_status. So I assumed that I simply had to do request->set_cdata to set the HTML body corresponding to the status. But this was incorrect.
The correct approach was to use me->write (me referring to the BSP page in the DO_REQUEST method). I know too little about BSP to explain why the request and the BSP page are two different objects.
I came across this interesting article by Paul Hardy yesterday and in one of his screenshots he's using a pretty cool header/signature for his methods.