Hi friends!
In this post we will detail some of our experience in migrating packages from SAP B1If 1.x to SAP B1If 2.0, more specifically migrating packages related to a custom REST API for SAP Business One.
Our migration process basically involved three distinct processes, the last process of which has not yet been completed:
After the migration from 1.x to 2.0, some adjustments were required in several places for the steps to perform minimally in B1If 2.0. These adjustments for minimal execution maintained compatibility with 1.x.
Therefore, to get the expected improvements with B1If 2.0, it will still be necessary a Tuning step, aiming to eliminate the 1.x elements of the steps and migrate definitively from the "Smart Message Model" to the "Freestyle Message Model".
The first step in migrating a package from B1If 1.x to B1If 2.0 is to use the Migration Tool in SAP B1If 1.x. In this process we use the option [Create Scenario for Each Step] in Package Structure.
After the successful migration, we performed several adjustments in B1If 2.0 in order to have a functional version:
Below we detail some of the solutions found in this process of adjustments in the packages migrated to 2.0:
Finally, we list some limitations and difficulties encountered:
As a final result of the entire process, which required about 140 hours for about 70 scenarios steps, all packages related to the custom API REST for SAP Business One are operating correctly in SAP B1If 2.0.
Below is the final structure of the package in the SAP B1If 2.0 Deployment Panel.
The next steps of the conversion project will now involve Tuning the steps, aiming to make them 100% compatible with B1If 2.0 and thus obtain all the expected performance improvements.
As soon as we have details of this process that will still be carried out, we will launch a new article with all the details.
In this post we will detail some of our experience in migrating packages from SAP B1If 1.x to SAP B1If 2.0, more specifically migrating packages related to a custom REST API for SAP Business One.
Our migration process basically involved three distinct processes, the last process of which has not yet been completed:
- Migration Tool 1.x to 2.0
- 2.0 adjustments keeping B1If Compatibility
- 2.0 tuning to make B1If 2.0 pure package
After the migration from 1.x to 2.0, some adjustments were required in several places for the steps to perform minimally in B1If 2.0. These adjustments for minimal execution maintained compatibility with 1.x.
Therefore, to get the expected improvements with B1If 2.0, it will still be necessary a Tuning step, aiming to eliminate the 1.x elements of the steps and migrate definitively from the "Smart Message Model" to the "Freestyle Message Model".
1. Migration Tool
The first step in migrating a package from B1If 1.x to B1If 2.0 is to use the Migration Tool in SAP B1If 1.x. In this process we use the option [Create Scenario for Each Step] in Package Structure.
Migration Tool
2. Adjustments in Migrate Package
After the successful migration, we performed several adjustments in B1If 2.0 in order to have a functional version:
- Adjust the structure of the package, using the "Flow Editor" tool. Unfortunately the feature is only textual, and the possibility of dragging steps between scenarios would be welcome.
- Suitability for 1.x features not available in 2.0, such as "Call Scenario Step" in synchronous mode.
- Replacing global microservices defined in another package (such as log write) with calls via the REST API or by SELECT JDBC.
- General adjustments related to Inbound and Outbound Properties, use of the variable $settings for [Global Properties], inclusion of Allways in Branch so as not to lose previous messages, etc.
Below we detail some of the solutions found in this process of adjustments in the packages migrated to 2.0:
- Internal Microservices of the package, implemented as synchronous processes. Solution: [1] use of [Include] for microservice call in the main step with simplified request and response handling and within Branch/Unbranch with Always, [2] use of inbound/outbound ENQI/ENQO in the synchronous step, [3] need to add alone [External Adapter Call] for each distinct [Call Adapter] performed in the synchronous step (e.g., JDBC.1, 1, B1SJ.1) to create the respective portID in the main atom (eliminating error "XCE009 Unknown port ID").
- External Microservices to the package, implemented as synchronous processes. Solution: [1] in some cases a new endpoint was created in the base Custom API and the synchronous [Call Scenario Step] was replaced by [Adapter Call] HTTA.1; in other cases it has been replaced by [Adapter Call] JDBC.1.
- Inbound Configuration: [pltype] must be removed; if it is equal to xml generates error in queryParams and if it is equal to json gives problem with GET.
- Outbound Configuration: Included are [httpheader.htta.reporterror]=true and [htta.returnpltypeforce]=json
- Header parameters: You must remove the vpf prefix.
- HTTA.1: Unexplained error when using a created Xform instead of a migrated Xform, requiring the use of migrated Xform to make it work. In the migrated Xform the "sysid" is empty and works, in the created Xform the "sysid" is equal to the reference atom and gives the error "Reference SysId missing in SLD". Even changing from "jrexml" to "sapxml" in BizFlow didn't help.
Inbound HTTP
Finally, we list some limitations and difficulties encountered:
- Inbound Timer: the options of setting the recurrence values for the CRON Adapter in a fixed mode or with the need to create SLD T.AnySystem seemed confusing to us, and we considered that this definition should have the flexibility found in version 1.x (where the Schedulers are defined in the Setup phase).
- Inbound HTTP RESTfull: Endpoints in HTTP scenarios will now always have an endpoint containing the package, scenario, and step names and the deployment name. With this, it was necessary to create new steps for endpoints that used a subpath of the RESTfull URL.
- Obfuscation only encrypts XSL files but does not encrypt the Step flow, allowing changes even in obfuscated package. We believe that the reason for this is that in B1If 2.0 the definitions of Inbound and Outbound are carried out in the flow itself.
As a final result of the entire process, which required about 140 hours for about 70 scenarios steps, all packages related to the custom API REST for SAP Business One are operating correctly in SAP B1If 2.0.
Below is the final structure of the package in the SAP B1If 2.0 Deployment Panel.
Deployment Panel
3. Tuning in Migrate Package
The next steps of the conversion project will now involve Tuning the steps, aiming to make them 100% compatible with B1If 2.0 and thus obtain all the expected performance improvements.
As soon as we have details of this process that will still be carried out, we will launch a new article with all the details.
References
- SAP Managed Tags:
