I will focus on existing and new SAP partners who wish to connect their cloud offerings to S/4HANA customers or migrate their existing add-on to ABAP clean-code code. In this article, I will explain in more depth from a customer’s point of view which Extensibility Options fit the best different use cases for an SAP S/4HANA Cloud system.

As Software vendors like SAP consistently deliver best-practice solutions that should fit multiple customers. This means there will always be a gap between the requirements for your business processes and the software solution delivered to support them. There are several ways to close this gap. You can manage the gap by supporting it with manual procedures, but you can also try to solve it by extending your software solution with other solutions and custom development. In this article, I will focus on the following topics:

1. Adopt your system by customizing your business processes
   
2. Add ready-made solutions like SAP cloud products, SAP third-party add-ons, and SAP cloud partner solutions
   
3. Personalize the UI using S/4HANA Personalization Options
   
4. Build your own extensions using S/4HANA Extensibility Options

Customize your business processes.

The best and cheapest option to solve the gap is to customize your business process to fit into SAP’s best practice processes. By using the predefined templates and configuration options of S/4HANA, you can tailor your business processes to your needs. For S/4HANA public cloud, there is a specific cloud application called SAP Central Business Configuration, which enables you to scope, configure, and implement end-to-end business processes for your cloud solution from a central place. After setting up your S/4HANA Cloud public edition, you can use the Implementation Activities app for further configurations, such as in SAP ECC and other S/4HANA editions, using transaction SPRO.

SAP cloud products, SAP third-party add-ons, and SAP cloud partner solutions

When a gap remains between your business processes and the customizing, you should consider SAP cloud products, SAP S/4HANA on-stack third-party add-ons, or side-by-side SAP cloud partner solutions in the SAP store.

As mentioned in my previous article, SAP simplified the supported processes in the S/4HANA Cloud public edition. It moved functionality to other SAP Cloud products, providing even more functionality in their domain. These solutions can provide even more functionality than previously available in SAP ECC. In the last couple of years, SAP has invested a lot in integrating these SAP Cloud products with S/4HANA and has now positioned the complete integrated portfolio as Cloud ERP. However, with the simplification of S/4HANA, customers can also choose products from an SAP competitor to solve the missing functionality in S/4HANA for some domains. This results in some challenges that I will discuss later in this article.

Another way to solve the gap between business processes and SAP software is to install a third-party SAP add-on to the S/4HANA system or connect your system to a SAP side-by-side cloud partner solution. In the past, add-ons were often considered, and for SAP ECC, many add-ons were available. But for S/4HANA Cloud editions, this isn’t the case yet. SAP has previously asked its partners to build their solutions outside S/4HANA, in SAP Business Technology Platform (BTP), and provide this as an SAP cloud partner solution. SAP even set up a partner program to run these solutions as a SAAS offering on BTP, which makes it very easy for S/4HANA customers to consume these partner solutions. The possibility of closing the gap by providing SAAS offerings on BTP by a SAP cloud partner is a crucial aspect of SAP’s strategy to extend its footprint into the market. And from that aspect, I expect many more SAP cloud partner solutions soon.

However, besides the SAAS offering, I expect many more S/4HANA on-stack add-on products soon. SAP has launched the embedded ABAP Cloud stack of S/4HANA Cloud public edition 2023. This allows smaller SAP partners to deliver their add-ons based on ABAP Cloud to customers via a controlled git-based multi-off delivery. A SAP certification for this addon is unnecessary because the code follows the SAP clean core paradigm, which will be checked when you deploy your code. This removes the barrier for many SAP partners, consulting companies, and independent consultants to build and provide add-ons to their customers.

S/4HANA Personalization Options

In some cases, the gap is small and depends on the user of the S/4HANA system. You can influence how users work with the system by providing the proper business role. Authorizations and using default values in the Fiori Launchpad already allow you to influence and limit user entry, but you can go further.

S/4HANA Uis, based on Fiori Elements, can be configured to present data in a personalized way. You can add and remove filters and their values, change how the data is displayed, and store and share this personalized look and feel.

S/4HANA Key User Extensibility – UI adaption

Sometimes, these personalization capabilities aren’t enough, and you want to adapt the UI and change the look and feel of the applications to your needs. You can change or hide titles, buttons, and label names and reorder and hide fields and sections. If the S/4HANA app supports this option and you have the proper authorization, you will find the UI Adapt button in the menu of your Fiori Launchpad profile.

UI adaptation, default values, and personalization are strong capabilities of S/4HANA Cloud that can improve user experiences and reduce users’ knowledge gaps.

S/4HANA Extensibility Options

For some business processes, more than all of the options above are needed, and the only solution is to use the other S/4HANA Extensibility Options. My previous article mentioned that SAP provides eight possible S/4HANA Extensibility Options, as seen in the picture above. Before I elaborate on them, I want to address two topics that are relevant to understanding the S/4HANA Extensibility options:

1. On-stack extensions versus Side-by-Side extensions
   
2. Low-code versus Pro-Code

On-stack extensions versus Side-by-Side extensions

On-stack extensions are S/4HANA extensibility options embedded in the S/4HANA system. All capabilities, authorizations, support, and maintenance are directly dependent on the availability of your S/4HANA system, and these extensibility options are included in the S/4HANA licenses. Because these extensibility options run on the same instance as the S/4HANA system, they are tightly coupled. This allows for adopting extensions to standard S/4HANA processes and handling big datasets with excellent performance.

Side-by-side extensions are S/4HANA Extensibility Options, which run on their own instances in the SAP BTP Cloud environment. These extensions are loosely coupled with S/4HANA. These solutions will exchange data with S/4HANA through APIs and events. These extensibility options are primarily suitable when:

• The on-stack extension significantly impacts the available S/4HANA runtime resources;
  
• Casual or external users must participate. Still, you don’t want to give them direct or full access to S/4HANA;
  
• you need an extension, which, besides S/4HANA, also needs data from other cloud resources;
  
• you need solution extensions for multiple S/4HANA systems.

Low-code versus Pro-Code

The S/4HANA extensibility options are split into low-code and pro-code options. The pro-code option is the most flexible and powerful option for realizing your extensions, but you also need a professional SAP developer to build the extension. In many cases, you can realize the extensions by just adopting some slight modifications using applications that do this through minimal coding, supported mainly by a visual approach. In this case, you don’t need a professional SAP developer in the IT department; you can let business users with some coding knowledge build the extension. These types of business users who are using low-code applications are also known as citizen developers.

S/4HANA Key User Extensibility Option.

The S/4HANA Key User Extensibility Option is a low-code extensibility option in the S/4HANA system. It provides a set of Fiori apps to manage the most common changes needed to User Interfaces (UIs) and business processes.

Extend standard SAP UIs, reports, and APIs with custom fields.

With Custom Fields, you can create new custom fields and extend existing SAP data structures with calculated fields. This allows you to customize applications and adapt their UIs, reports, email templates, form templates, and APIs.

This custom fields capability allows storing, calculating, and using additional fields in your S/4HANA applications. It will follow SAP’s Clean Core strategy and is stable for upgrades and future-proof. With this option, you don’t need to improperly use existing SAP fields of SAP applications, which has happened a lot in the past in SAP ECC.

Influence the behavior of a S/4HANA application.

With Custom Logic, you can influence the behavior of standard S/4HANA applications. It will replace all the options we had in the past in SAP ECC, such as user exists, modifications, implicit enhancements, and enhancement spots. SAP has released predefined extension points in its standard SAP code lines, which can be influenced by custom code. Predefined extension points are available as business add-ins (BAdIs), and you can add the logic you need with this app. You can use a limited set of statements to influence the behavior of standard SAP business objects, interact with your custom business objects in the system, and even call services outside the S/4HANA system to create, update, or retrieve data from an external resource. To call services outside S/4HANA, you can use the Custom Communication Scenario app to configure the connectivity.

Implementing released BAdIs is the only future-proof solution in SAP’s Clean Core strategy that can influence the standard logic.

Building simple Custom Business Objects, transactions, and APIs.

With the Custom Business Object app, a citizen developer can develop small custom S/4HANA applications and backend services for new developments in S/4HANA and replace current custom-built applications in SAP ECC. The app allows you to create a custom data model with nodes and fields, add limited business logic such as determinations and validations, and generate the custom business object, the UI, and the backend service. When artifacts like fields, structures, value help, and methods are needed for multiple Custom Business Objects, you can use the Customer Reusable Elements app to build these artifacts.

The custom business object can be used in the custom logic of a standard SAP application. It can also be accessed as a Fiori application by S/HANA users when the object is added as an extension to an existing catalog using the app Custom Catalog Extensions. The custom business object can also be used by applications outside S/4HANA when the object’s backend service is generated and made publicly available after you process it with the app Custom Communication Scenario.

Make external web resources available.

The Custom Tile app allows you to create Fiori tiles in your Fiori Launchpad to access external web applications. Since the user must already have access rights to external web applications, this solution is best for other SAP cloud applications, publicly accessible internet applications, and custom-built and third-party applications running on SAP BTP, which shares the same identity provider as S/4HANA.

Assemble analytical reports and custom data sources.

In the clean core strategy of S/4HANA, you can’t access SAP tables directly anymore, but you should access your data through so-called CDS views. The CDS Views can be a projection layer on top of these tables but can also read data from other CDS views. The CDS views serve as a source for transactional and analytical apps, value-helps, APIs, and data extraction. SAP uses these CDS views to migrate its existing data model slightly to a new Virtual Data Model. The Virtual Data Model of SAP has many CDS views, but only the released CDS views can be used by SAP partners and customers.

The Custom CDS View app allows customers to assemble custom CDS views for analytical and read-only external APIs. They are based on released CDS views and other custom content, such as custom business objects and other custom CDS views. With the app, you can create a CDS View that selects fields from multiple data sources and adds new calculated fields. You can refine these chosen fields’ properties, add filters to refine the result set and add and maintain parameters for the usage within your view.

The Custom CDS View app also allows users to create CDS Views with analytical capabilities, the so-called Analytical CDS View. These views can be used in S/4HANA analytical tooling, the S/4HANA query builder app Custom Analytical Queries, S/4HANA KPI Designer, and APF Configuration Modeling.

Reports and overview page.

In SAP’s Clean Core strategy, SAP Fiori is the only supported UI for custom-built applications in S/4HANA. This means that all UI capabilities of SAP ECC, such as ABAP reports, ABAP dynpro, BSP, and WebDynpro, are obsolete and should be replaced.

However, this is easy for Custom Business Objects or custom CDS views. When these artifacts are exposed as S/4HANA external APIs, these APIs can be used as a source for the Fiori Elements tooling. With this tooling, a Fiori List Reports, Fiori Analytical List Page, and Fiori Overview Page can be generated in a few steps. A frontend developer can take this as a base, add the needed UI capabilities to the generated application, and deploy it to the S/4HANA system as a Custom Fiori App.

Real-time analytic dashboards.

When the analytical capabilities in S/4HANA and Fiori Elements don’t fit your business needs, you can always use a side-by-side tool like SAP Analytics Cloud. This is appropriate when using S/4HANA and other data resources to analyze and predict business outcomes and want to use the outcomes for business intelligence and enterprise planning.

S/4HANA supports this Extensibility Option by providing a live data connection between S/4HANA and SAP Analytics Cloud based on SAP’s optimized InA protocol. This allows SAP Analytics Cloud to query S/4HANA’s data sources in real time and react directly to changes.

The SAP Analytics Cloud Extensibility Option allows real-time dashboarding of business processes. The live data connection, machine learning, and artificial intelligence capabilities of SAP Analytics Cloud will also take the S/4HANA-supported business process to the next level, which isn’t possible with SAP ECC.

Process automation and interaction with occasional SAP users.

In most companies, a business process starts with collecting, checking, and approving information before it is entered into an ERP system. This process is usually manual and supported by unstructured data tools such as email, spreadsheets, documents, and notes.

The market recognized this and developed more structured, low-code solutions to support these processes. SAP entered this market, too, with SAP Build, a citizen development tool for building workflows and simple UIs to collect, check, and approve data for users who do not need access to a S/4HANA system.

When SAP examined these processes, it saw another significant improvement opportunity. Most processes had repeated steps, such as collecting and interpreting data from known sources and manually entering data into applications and unstructured tools, which robotic engines and artificial intelligence can easily automate without interaction with a user. This process automation capability was also added to the SAP Build portfolio.

SAP positioned SAP Build Process Automation as a side-by-side extension possibility for additional customer-specific processes and automation on top of S/4HANA. It will also replace the customer ABAP workflows we know from SAP ECC, which is no longer possible in S/4HANA.

Integrate your business processes in the cloud.

Many companies use software products other than SAP to automate their business processes. They want to work more closely with their business partners and can gain value by outsourcing part of their business processes to them. Companies also want to automate data exchange between ERP and their manufacturing systems.

ERP systems have exchanged data with each other almost from the beginning. In the early days, users had to make manual entries, but nowadays, they can use files and spreadsheets or even connect systems with APIs using EDI or internet-based networks. The data model should be aligned, and integration products should be introduced to map the content and API structures of the connected systems.

Integration becomes even more critical with the simplification of S/4HANA and the move of business functionality to other Cloud products. Traditional integration, as we know from SAP ECC, is not enough. By moving functionality to other cloud products, S/4HANA also loses the tight coupling between the business processes we had in SAP ECC. APIs alone are not enough to solve this issue. S/4HANA needs to provide notification events to connected systems when situations in the supported business processes are changed. The traditional integration architecture needs to shift to an event-driven architecture, precisely what SAP offers with its Cloud Integration Suite and S/4HANA Cloud events and APIs.

Cloud Integration Suite offers traditional EAI/B2B integration options, the capability to connect to non-SAP products using open connectors, and SAP Graph, a fully event-driven unified data model on top of SAP’s Cloud products.

Building your enterprise-grade cloud applications

When do you need a professional developer to build your custom application? As soon as you cannot solve the gap in our S/4HANA business process by connecting other software products, building process automation workflows and UIs, or modifying standard SAP screens and logic with key user extensibility options, you need a professional developer.

Of course, you can build this application on any platform in any language. However, when data from SAP Cloud products is involved, creating applications with SAP tooling is the best solution. From the perspective of S/4HANA, you can develop the application on-stack or side-by-side.

On-stack is the best solution if you need tight integration with your S/4HANA data or users. In this case, you build your application directly with ABAP Cloud on the embedded ABAP environment, and you can use all of S/4HANA’s capabilities. This is also known as SAP S/4HANA Cloud Developer Extensibility.

On the other hand, when you need an application loosely coupled from S/4HANA and mostly runs standalone or heavenly, depending on other SAP cloud products, the side-by-side extension SAP Build Code on BTP is the best solution. With SAP Build Code, a professional developer can build enterprise-grade Java and JavaScript cloud applications fast and with high quality, supported by AI-based code generation.

SAP BTP also offers an ABAP environment for developing side-by-side applications. When you upgrade to the S/4HANA cloud, this environment can be used to build new, future-proof, clean-core ABAP applications while still running SAP ECC. After the upgrade, these applications can later be moved as SAP S/4HANA Cloud Developer Extensibility of the embedded ABAP environment of your S/4HANA. However, you can also move your SAP S/4HANA Cloud Developer Extensibility applications to the SAP BTP ABAP Cloud environment when the applications significantly impact the runtime resources on the performance or cost of your S/4HANA system.

As I will explain in my next article, the SAP BTP ABAP environment can also be a good option for SAP solution partners to provide additional S/4HANA functionality in a software-as-a-service model.

Conclusion

SAP supports many different S/4HANA Extensibility Options described in this article to help customers solve gaps in supporting their business processes with S/4HANA. SAP analyzes customers’ needs by examining SAP ECC and translating this into options, considering their clean-core strategy for S/4HANA. This allows customers to adjust their business processes and offers many opportunities for SAP solution partners and cloud vendors to add value to the SAP ecosystem.

The post Which S/4HANA Extensibility Options should I use as a SAP customer? first appeared on ERP Q&A.

Ever since the advent of Launch Wizard, we have been waiting for this feature in Launch Wizard service as we see many customers running their SAP applications on SAP ASE such as SAP NetWeaver, SAP Process Orchestration (PO) and Solution Manager. This new feature will help customer and implementation partners to speed up SAP deployments on SAP ASE database during their implementation projects.

In this blog post, we will walk you through essential steps that are required to deploy SAP application based on SAP ASE database using the automation capabilities of AWS Launch Wizard for SAP.AWS

AWS Launch Wizard for SAP:

AWS Launch Wizard for SAP is a service that helps in deployment of SAP workload based on SAP HANA and SAP ASE database in AWS cloud using a guided wizard-based experience & APIs for programmatic deployments. Users will have to provide inputs related to their SAP workload like SAP application and database versions, landscape settings, deployment details etc. Launch Wizard identifies the appropriate AWS resources to deploy and run your SAP application.

Launch Wizard for SAP not only automates the SAP deployments, but also helps in EC2 instance selection and configuration, resource selections, cost estimation, installation of Data Provider for SAP etc… For the complete list of features refer to Launch Wizard User Guide.

Prerequisites:

Before getting started, ensure that you have the following in place:

• Key Considerations: Current Launch for SAP supports deployment of SAP ASE version 16 SP4 PL4. Also, only single instance deployment is supported as of today.
• AWS Account: Make sure you have an active AWS account with the necessary permissions to access AWS Launch Wizard.
• SAP System: Have an SAP build sheet ready with all the information on SID, instance number and file system layout and so on.
• Launch Wizard Access: Ensure you have access to AWS Launch Wizard and that it’s available in your AWS region and supported by AWS.
• Download SAP packages: We can follow the guide below to download SAP packages and pay special attention to SAP ASE software.
• Upload SAP software to Amazon S3.

Testing Steps:

1. Launching AWS Launch Wizard:

• Log in to the AWS Management Console and navigate to the AWS Launch Wizard service.
  
• Select the SAP workload type.
  
• Define Infrastructure.

2. Network Configuration:

• Define the network architecture for your SAP deployment, including VPC settings, subnet configurations, and security groups.

3. Selecting SAP ASE as the database:

• Select SAP Application Type (we choose Netweaver stack on SAP ASE) and Application (we choose Netweaver ABAP). One can also choose Application as Netweaver Java (single stack) or Solution Manager (dual stack)
  
• Configure SAP system parameters.
  
• Ensure that the selected parameters align with the requirements of your SAP landscape.

• Configure storage settings, specifying the type, size, and configuration of storage volumes for your SAP system and SAP ASE database.
  
• Choose the appropriate Amazon EC2 instance type for your SAP workload, considering performance requirements and resource utilization.

4. Review and Launch:

• Review all the configured settings to ensure accuracy.
  
• Click on the ‘Deploy’ button to initiate the deployment process.

5. Monitor and Validate:

• Monitor the deployment progress through the AWS Launch Wizard console.
  
• Once deployed, validate the SAP system’s functionality and SAP ASE database connection.

Conclusion:

In this blog you have seen how easy it is to deploy SAP workload based on SAP ASE database in AWS cloud. AWS Launch wizard for SAP takes away heavy lifting from project consultants & makes it easy and quick for customers and partners to deploy their SAP workloads. Hence reducing the errors in the deployment cycles and overall reduction in project implementation timelines. Launch Wizard for SAP already supports SAP deployment based on SAP HANA and now with the SAP ASE deployment support, it’s convenient for the customers to use single service to meet the majority of SAP workload deployment needs for their SAP landscape in AWS cloud.

The post Automate SAP Application Provisioning on SAP ASE database with AWS Launch Wizard for SAP first appeared on ERP Q&A.

Automation of business process through APIs is a powerful approach that allows integration with SBPA tenant, enabling you to interact with and manipulate data programmatically.

Deploying an automation BOT as a web service API involves making your automation functionality accessible over the internet so that other systems or users can interact with it by the API calls. These API calls can be executed from 3rd Party API tools like POSTMAN.

Why are we triggering BOT through API?

Triggering a bot through APIs offers several advantages. Bots are software applications designed to automate tasks, interact with users, and perform actions based on predefined rules or AI capabilities. When we trigger a bot through APIs, it means we are initiating its execution or instructing it to perform specific tasks programmatically using API calls.

APIs allow seamless integration between bots and other applications, services, or databases. By triggering the bot through APIs, we can connect it with various platforms, enabling the bot to access and exchange data. Through APIs, we can initiate multiple instances of the bot simultaneously. This feature helps distribute workload and process tasks in parallel, enhancing performance and scalability.

By triggering bots through APIs, we can maintain centralized control and monitoring. API calls can be logged, audited, and tracked, providing a clear view of the bot’s activity.

Use case:

In this use case we are going to see creating Sales order scenario in SAP S/4H System. This UI Automation scenario will be triggered from API calls via POSTMAN.

Pre-requisite:

• A deployable Bot
  
• Access to the BTP Cockpit
  
• Postman application.

Then these following steps need to be performed sequentially

• Deploy the Bot
  
• Create automation trigger and expose API endpoint
  
• Configuration of BTP Cockpit
  
• Configuration of POSTMAN.

1) Deploying SBPA Bot:

1. First click release button at the top right corner to release the bot.

2. Give comment, then click release

3. Once it is released, we can be able to see the Deploy button on the right corner. Now click on deploy

4. Click next and deploy.

5. Once the bot deployed, navigate to the monitor tab to add automation trigger. Here click on the Go to Monitor > Triggers button.

6. Select trigger type as API and click next

7. Now, provide some name for the trigger, choose the automation flow which executes once the API is called

8. Now we will get the HTTP Method, URL and input Payload structure.

Now we have successfully deployed the Bot and created the Automation trigger.

2) Configuration of BTP Cockpit:

1. Navigate to the BTP Cockpit centre->Services and Instances page

Create an instance of the SAP Build Process Automation service, using the standard plan

2. Once you created, wait till the status turn into green

3. Now click on the three dots to add a Service Key. Provide service key name and click create

4. Once the service key created, Click view to see those credentials

5. We are going to use OAuth authentication like all other BTP services. OAuth authenticates the client application not the user. Please note down the following credentials in notepad these will be used in the following steps.

• Authentication URL
  
• Client ID
  
• Client Secret

3) Configuration of POSTMAN

1. Open POSTMAN application in your desktop, create a new collection and add a request

2. Under Authorization tab, select type as OAuth 2.0 and select Request Headers in the drop down.

3. Now provide the following credentials on each textbox

• Access Token URL
  
• Client ID
  
• Client Secret

Choose Client Authentication as a Send as a Basic Auth header.

Give the access token URL as per the following format.

<Authentication URL>/OAuth/token

4. Now click on Get New Access Token

5. A New Token will be generated, Use this token for further authorizations

6. Under Header tab create a new header irpa-api-key

7. Go to the tenant, under Settings tab click API Keys->Add API Key.

8. Provide API Key name and click Next

9. Click create

10. Note down the API Key, it will be shown only once.

Finally Add the generated API key to POSTMAN.

Execution

Now the Bot is ready to execute

Give the payload as per the Input schema generated and click Send.

for a successful API call, we will get the response as 201 Created and the Job ID will be shown in the body. Which means the job has been added in the queue for execution.

To check the execution status of the bot, navigate to tenant and click Monitor->Automation Jobs

Note:

• The desktop agent should be in Unattended Mode
  
• While giving the JSON Payload data, we must maintain exact naming conventions and datatypes.

The post Deployment of SAP Build Process Automation(SBPA) Bot as a Webservice and triggering it from POSTMAN first appeared on ERP Q&A.

Enterprise Automation

Integrating, analyzing, and automating end-to-end business processes is critical in today’s digital landscape. To help customers stay ahead of the competition, SAP offers enterprise automation, a solution that combines the value of SAP Integration Suite, SAP Signavio, and SAP Build. Enterprise Automation allow customers to identify, model, integrate and automate processes end to end across heterogeneous landscapes. This helps companies grappling with disconnected processes and ensures they are automating processes that need it the most.

Ecosystem

The enterprise automation solutions from SAP connect to everything in your environment

• 80+ standard adapters: SAP Applications, mail, various protocols (such as Odata), HTTPS, FTP, RFC and more
• 170+ non-SAP connectors: Gmail, Dropbox, Evernote, etc, which are specific to Integration Suite
• Own adapter development with an Adapter Development Kit
• Open connectors (SAP Integration Suite)

SAP commitment to deeper partnerships to serve customers across different tools

• Process Composability with 3rd party automation tools: UiPath, Automation Anywhere, Microsoft
• Customers can continue using existing and familiar automation tools without disruption
• Flexibility and customization with the right tools to cater to specific automation project requirements

Partners contribute actively to our store and pre-built content

• Unified Store & Marketplace for SAP, partners and customers. Includes pre-built industry & LoBcontent, integration packages, and more
• Discover industry-specific content for existing SAP systems, like SAP SuccessFactors, SAP Ariba, SAP S/4HANA, etc
• Content updates delivered by SAP partners with industry expertise and knowledge

Automation Anywhere Integration

This section provides information about setting up the SAP Business Technology Platform account to consume the SAP Build Process Automation Update Opportunity Stage template as well as the Create Lead template.

The templates mentioned above are intended to simplify the integration of automated business processes from SAP with Salesforce data. The Opportunity Update template automates the steps required to change the pipeline stage of any opportunity within Salesforce to which the defined user within the automation has the ability to edit. The Lead Creation template automates the steps required to create a new Lead record within Salesforce, allowing you to pass in all required attributes for the new Lead.

Both of the automations mentioned above follow a similar flow given the actions provided within each and both are intended to be fully customizable to meet the needs of your business and the customizations you may have applied to your own Salesforce instances. As can be seen from the diagram below, a Form is provided within the SBPA template which captures input data to the process. That data is then encapsulated and sent to the target Automation Anywhere Control Room which will will deploy the task automation to complete the work wihtin Salesforce. The outcome of the automation is pulled from the Automaiton Anywhere Control Room and can be viewed in the monitoring output which SBPA provides.

The Actions included in the templates above deploy the following API’s which are published into the SAP Build Store as a part of the template project to make it simple for any developer to quickly configure against your own target systems for execution via SBPA:

Automation Anywhere Authentication V1

• POST – /v1/authentication
• Requires a valid user account into Automation Anywhere Control Room
• Optional: User should be assigned “Generate API-Key” permission if choosing to utilize API Keys over Passwords

Automation Anywhere Bot Execution Orchestrator V3

• GET – /v3/activity/execution/{id}
• POST – /v3/activity/list
• Ensure user has been assigned the “View my activity” permission

Automation Anywhere Bot Deploy V4

• POST – /v4/automations/deploy
• Ensure the user has been granted the following Control Room permissions
• View my bots
• Run my bots
• View Content permission on the folders containing the bots
• Run permission on the folders containing the bots

The user should belong to a role which has access to Bot Runners and optionally is also a consumer of a Device Pool if looking to deploy the automations to the first available device in a pre-configured pool of devices.

Prerequisites

The automation templates for Update Opportunity Stage and Create Lead provide a set of actions that can be incorporated into any SBPA Process Flow and requires the following services to be available to successfully run:

• SAP Build Process Automation to orchestrate the process.
• Salesforce CRM
• Automation Anywhere A360 Control Room on version A.30+

Configuration

To call these process actions, a HTTP destination is required in the SAP BTP account where the SAP Build Process Automation is subscribed.

Update Opportunity Stage and Create Lead templates require SAP Build Process Automation subscription or CPEA contract. Follow the setup and configuration section.

Setup SAP Business Technology Platform Cockpit

Destination Configuration

Configure SAP Build Process Automation HTTP Destination:

Add the following Additional Properties to your destination configuration:

Setup Automation Anywhere Content

Both of the scenarios in this template, Update Opportunity Stage as well as Create Lead, are dependent on Automation Anywhere bots to perform the automations against Salesforce. An exported package of automations has been provided for you and can be downloaded directly from the SAP Build Store listing page from which you deployed the template. Follow the directions below to configure and deploy the Automation Anywhere bots.

1. Download the ZIP file to your local device
2. Log into Automation Anywhere Control Room with a user that has the following permissions:

a. View my bots

b. Import bots

c. Check in permissions to Public folder

3. Navigate to the Automation menu item
4. Select Import located on the top right of the page
5. Click the Browse button to navigate to the folder containing the downloaded ZIP file
6. Leave the password field blank
7. Under Import bot to, select Private Tab
8. Leave the default option selected for “During import if a file already exists”. This option allows you to specify how the system should behave if it encounters a matching file and folder
9. Click the Import bots button located on the top right of the page
10. The import process may take 1-2 minutes to complete. You can refresh the folder listing under your Private tab to check if the artifacts have been successfully generated. You should see the following folder structure created:

• Bots
  • SAP Build Process Automation
    • Create New Lead
      • Config
    • Update Opportunity Stage
      • Config

11. Once the automations have been fully imported, you’ll need to make some updates. Both task automations have been designed to utilize Control Room Credential Vault to read Salesforce login attributes at runtime. See documentation here on setting up Credential Vault lockers and credentials.
12. Once you’ve set up your credentials, you can update the Salesforce Authentication steps in both the Create Salesforce Lead automation and the Update Opportunity Stage automations

13. Both automations have been designed to read re-usable environment values from the Config.xml file located in their respective Config folders. You can open and edit these files directly from within Control Room. Make edits to the values under the appropriate section which indicates where the automations have been deployed to; Development, UAT or Production.

14. Navigate to the Global Values menu item

15. Create a new Global Value called Environment

16. Assign a value to the variable of either Development, UAT or Production, depending on which of these best represents the purpose of the Control Room in your development lifecycle.

17. Update either automation with additional customizations as needed to support your use case or your customizations within your own Salesforce instance. For example, the Create Salesforce Lead automation only utilizes standard Lead fields to create the target Lead record. Add additional input variables and update the Dictionary as required to support your customizations.

18. Check your automation into the Public folder when ready

19. Once your automations have been checked in, open them from Public and make note of the ID contained in the URL.

Eg: /#/bots/repository/public/taskbots/7289/view

The 7289 above is the ID of the automation in the Public folder and this value will be used when deploying the automation from SBPA in the following steps

SAP Build Process Automation

In this section, you’ll find detailed information on the required or optional customizations for components within the Update Opportunity Stage and Create Lead Process Automations.

Update Opportunity Stage

Configure Process

Automation Anywhere is currently planning and developing the required authentication flows to support SAP OAuth within Destinations. As a result, the currently supported authentication method in the Authenticate User action relies on providing a the username as well as either a password or an API Key for the user which will be used to log into the Control Room via API to deploy the automation. Additional input parameters include the Bot ID as well as the Unattended Bot Runner ID which will be used to deploy the bot. Both of these values can be captured from the Automation Anywhere Control Room. These values can be passed in at runtime of the process, leaving only the configuration of the HTTP Destination before running the process.

As the content package is designed to be reusable, you will need to define a Destination which will allow the actions to determine which Control Room end point they need to communicate with for each respective call out. To configure HTTP Destinations in your environment, review the SAP Documentation by clicking here.

*Ignore this step if you already configured an HTTP destination to your Control Room as defined in the pre-requisite configurations above

Configure Forms

While no updates or modifications are required on the Input Form for the Update Opportunity Stage process automation, the form does allow for flexibility in how the Opportunity is located in Salesforce. If choosing to use the Opportunity ID field, ensure that you pass in the Salesforce record ID of the opportunity which can be found in the URL of the opportunity record page.

If you are not able to locate the record ID, you can skip directly to the middle section of the form on which you can instead provide the Account Name as well as the Opportunity Name exactly as they have been defined in Salesforce. Where the automation is able to find a unique match on these values, the opportunity stage update will be performed.

The last required attribute on the form is the pipeline stage name you would like to update the opportunity to. A value must be selected in order to run the process.

Create Lead

Configure Process

Automation Anywhere is currently planning and developing the required authentication flows to support SAP OAuth within Destinations. As a result, the currently supported authentication method in the Authenticate User action relies on providing a the username as well as either a password or an API Key for the user which will be used to log into the Control Room via API to deploy the automation. Additional input parameters include the Bot ID as well as the Unattended Bot Runner ID which will be used to deploy the bot. Both of these values can be captured from the Automation Anywhere Control Room. These values can be passed in at runtime of the process, leaving only the configuration of the HTTP Destination before running the process.

As the content package is designed to be reusable, you will need to define a Destination which will allow the actions to determine which Control Room end point they need to communicate with for each respective call out. To configure HTTP Destinations in your environment, review the SAP Documentation by clicking here.

*Ignore this step if you already configured an HTTP destination to your Control Room as defined in the pre-requisite configurations above

Configure Forms

The Create Lead Input Form does not require any updates or modifications to use. The form has been designed to work with all Salesforce Standard fields for a Lead record, allowing you to pass in a combination of required as well as optional values which will be used to create the new Lead record in Salesforce. The required fields must be provided a value in order to execute the process.

Automation Anywhere SBPA Command Package

Automation Anywhere Command Packages provide a collection of actions that you can configure and use to build automations. To make integration with SAP SBPA even simpler, Automation Anywhere has built a command package that can be downloaded from the Automation Anywhere Bot Store marketplace which provides the following benefits:

• Easy integration between Automation Anywhere A360 and SAP Build Process Automation
• Start processes in SAP Build Process Automation
• Get Process Context
• Get Process Status

The key use cases the command package can help unlock include:

• Start a process in SAP Build Process Automation
• Check the status of a process instance
• Get the process context

The post Enterprise Automation with SAP Build Process Automation and Automation Anywhere first appeared on ERP Q&A.

Scenario:

The scenario is as follows: We have SAP Build Process Automation running on the SAP Business Technology Platform (BTP), while the on-premises systems expose their endpoints. In order to establish the connection, we will configure the Cloud Connector, create a destination, create a Build Actions project, and test it in a Build Business Process.

Let’s dive into the steps required to set up this integration and leverage the power of SAP Build Process Automation in conjunction with the SAP Cloud Connector.

Prerequisite

Before proceeding with the steps outlined in this guide, it is essential to have an instance of the SAP Cloud Connector installed. While it is possible to install the Cloud Connector on a server, for the purposes of this demonstration, we will be using a Windows machine.

Second requirement is a BTP subaccount with a SAP Build Process Automation instance. To this subaccount we will connect the Cloud Connector.

1. Cloud Connector Configuration

The first step is to create a configuration in the Cloud Connector that connects to our subaccount and exposes the HTTP resource. For the purpose of this demonstration, I ran a small Node.js server on my Windows machine that outputs “Hello World”.

To create the configuration, navigate to the admin interface of the Cloud Connector and create a “Cloud to On-Premise” configuration.

In the provided screenshot, you will notice that I have exposed the internal host “localhost” on port 3333 using a virtual host named “internalhost”. This virtual host will be used for making requests from the BTP side. Currently, I have configured an unrestricted access policy, allowing access to all paths. However, in production scenarios, it is recommended to define access policies with more granular control.

Please note that it is crucial to ensure that you have exposed the necessary resources in your configuration. This ensures that the required endpoints are accessible and allows for successful communication between the cloud and on-premises environments.

The type of system in this case is Non-SAP System with the protocol HTTP. Notice – the internalhost is the virtual host that is mapping to the accessible host in the on-premises environment. To verify its reachability, you can utilize the “Check availability of internal host” button. This step is crucial as it helps ensure the correctness of your setup and validates the connectivity between the cloud and on-premises environments.

On the BTP end, we can check the cockpit and the connected Cloud Connectors in the respective menu tab. If you cannot see this tab, you may be missing some roles. In the image, you see my registered Cloud Connector and the backend system internalhost:3333 available.

2. Create Destination

After successfully registering the Cloud Connector, the next step is to create a destination. A destination serves as a means for services to access an API by handling the authentication and networking aspects.

By configuring a destination, you can simplify the process of accessing APIs by abstracting the underlying technical details. The destination takes care of handling authentication, network communication, and other necessary configurations, allowing services to focus on consuming the API and performing business logic without worrying about the underlying implementation.

Creating a destination provides a convenient way to encapsulate the necessary information, such as the API endpoint URL, authentication credentials, and other relevant settings. This abstraction helps streamline the integration process and facilitates secure and reliable communication between your services and the targeted API.

When creating the destination, there are several important details to specify. These include the name of the destination, the URL you want to access, and the type of destination. In this case, we will specify the URL as the virtual host “http://internalhost:3333”. To utilize the Cloud Connector, we set the proxy type to on-premise.

Additionally, when working with Build Process Automation, we require two additional properties to ensure the destination can be accessed from the Build Actions end:

1. sap.processautomation.enabled – Set this property to true.
   
2. sap.applicationdevelopment.actions.enabled – Set this property to true as well.

Once the destination configuration is complete, it is crucial to use the “Check Connection” button to verify that everything is configured correctly and the connection can be established successfully. This step ensures that the destination is functioning as expected and is ready to be utilized in your automation processes.

In the ideal case you get the green checkmark! But there are some common errors we need to discuss:

The “Backend not available” error occurs when the connectivity service is unable to locate the host you are trying to access. This could be due to the host not being exposed in the Cloud Connector configuration or a potential misspelling in the URL. To resolve this issue, it is important to revisit the URL and ensure that you are using the correct virtual host specified in the Cloud Connector configuration. Verify that the URL is accurate and matches the virtual host configuration to establish the necessary connectivity.

The second common issue that may arise is the “Resource not accessible” error. This occurs when the connectivity service successfully locates the backend you intend to connect to, but the specific resource (such as the subpath “/hello”) either does not exist or is not allowed to be accessed based on the rules defined in the configuration. To resolve this, ensure that you have included the correct path in the Cloud Connector’s resource configuration.

3. Create Actions Project

Now, let’s dive into SAP Build Process Automation and create an Actions project. In this case, since my API is not a standard one, I will create a custom API Specification. However, if you are working with a target system like S/4HANA, you can leverage the pre-defined API Specifications available in the SAP Business Accelerator Hub.

To proceed, navigate to “Build an Automated Process” > “Actions” > “Upload API Specification”.

{
  "openapi": "3.0.0",
  "info": {
    "description": "Demonstration Hello World",
    "title": "helloworld",
    "version": "1.0.0"
  },
  "servers": [
    {
      "url": "empty"
    }
  ],
  "paths": {
    "/hello": {
      "get": {
        "summary": "get hello",
        "description": "get a hello world message",
        "operationId": "get.hello",
        "responses": {
          "200": {
            "description": "Successful response",
            "content": {
              "application/json": {
                "schema": {
                  "type": "object",
                  "title": "Message Object",
                  "properties": {
                    "message": {
                      "type": "string"
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

The provided code snippet represents the API Specification, where I define the necessary details. In this case, the servers section is left empty as the URL will be retrieved from the destination configuration at a later stage. Additionally, I specify the available path as “/hello”.

It’s important to note that the path mentioned in the API specification will be preceded by the destination’s URL. Therefore, in our scenario, the complete URL for the request will be “http://internalhost:3333/hello”.

Another crucial aspect for the functionality within the low-code environment is defining the expected response structure. In this case, the response payload will consist of a plain object with the key “message”. To build and test specifications, you can utilize the website https://editor.swagger.io/. Be aware, that the response structure must match the specification; if, for example, fields are missing, you will be prompted with a schema error.

Once you have finalized the specification, save the file as a .json format and proceed to upload it to the Actions project.

Within the Actions Project, you will be prompted to add the desired actions, which you can proceed to do. Now, let’s move on to testing:

Within the selected Action, navigate to the “Test” tab. Here, you have the option to select the destination that serves as the basis for the request. For this demonstration, I will choose the ON_PREM_HELLO_WORLD destination that I created earlier. Once the test is executed, you will find the response payload displayed at the bottom. In this particular case, the test is successful, and I receive the expected message from my on-premises server.

If you encounter an error during the process, make sure to check the “View API” Section for any response body that might provide insights into the cause of the issue.

In the final step, we need to release and publish the Action to ensure its availability for consumption in an Automation Project. To accomplish this, locate the buttons located at the top right-hand side of the Actions editor. Click on these buttons and ensure that the status indicates “published.”

4. Add Action to Process

Lets create a Build Business Process Project and invoke the Action. Do so by adding a step in the Process on the + symbol.

We add a Action to the Process, configure its Destination field by creating a new Destination Variable we call in this case the same name as our real destination. To prove that we can now also use the data from the API, I created another Form and put its subject to the message variable from the payload. Go through the regular process to release and deploy this project.

In the Build Lobby we need to add this destination before we can also use it finally in the deployment.

Now when executing the start form, the process will trigger the API call and we should recieve a new Form in the Inbox (Can be found in the Build Lobby). We can see that the Result Forms has our message from the On-Premises HTTP Server as subject. Nice!

The post Accessing On-Premises HTTP APIs with SAP Build Process Automation and SAP Cloud Connector first appeared on ERP Q&A.

With the latest release of SAP Build Process Automation, you can now allow other business users who participate in the business process to perform an action on external systems, such as S/4HANA, Ariba, or SuccessFactors. This feature also provides clear information on who triggered a business process in the system .

Pre-requisites:

You can enable principal propagation by setting Run step on behalf of field of Action and Subprocess activity with preceding step. Details will be explained subsequently.

What is Principal Propagation?

Principal propagation forwards the identity of cloud users to a remote system or service (Cloud Foundry environment).

The Destination services let you forward the identity of a cloud user to a remote system. This process is called principal propagation (also known as user propagation or user principal propagation). It uses a JSON Web token (JWT) as exchange format for the user information.

The Destination service provides a secure way of forwarding the identity of a cloud user to another remote system or service using a destination configuration with authentication type OAuth2SAMLBearerAssertion. This enables the cloud application to consume OAuth-protected APIs exposed by the target remote system.

Supported scenarios:

• Cloud to on-premise (using the Connectivity service)
  
• Cloud to Cloud (using the Destination service).
  
• Scenario: Cloud to On-Premise: The user is propagated from a cloud application to an on-premise system using a destination configuration with authentication type Principal Propagation.
  
• Scenario: Cloud to Cloud: The user is propagated from a cloud application to another remote (cloud) system using a destination configuration with authentication type OAuth2SAMLBearerAssertion.
  In this blogpost ,I would cover the use cases related to the scenario Cloud to Cloud.

Scenario Cloud to Cloud:

Use Cases: Cloud to Cloud

• User Propagation from the Cloud Foundry Environment to SAP S/4HANA Cloud
  
• User Propagation between two Cloud Foundry Applications
  
• User Propagation from the Cloud Foundry Environment to SAP SuccessFactors

Configuration steps:

• User Propagation from the Cloud Foundry Environment to SAP S/4HANA Cloud
  
• User Propagation from the Cloud Foundry Environment to SAP SuccessFactors
  
• User Propagation between Cloud Foundry Applications

Now ,let’s see the use cases in detail.

Use Case- 1: Execute Principal propagation end to end in from CF to SAP S/4HANA Cloud

Steps:

Configure Destination in SAP BTP cockpit

• Create a business Project.

• Create a process with a subprocess, which will be configured to be executed by the preceding approver using principal Propagation mechanism.

• Click on the subprocess and select Form user as ‘Run step on behalf of’ section in Subprocess’s side panel.

• Configure the subprocess to create business partner by connecting to S4 system. Click on the action in the subprocess and select ‘Process Start’ as ‘Run step on behalf of’ section.

• Release and deploy the project with the below destination (as configured above)

• Trigger the process from Monitor tab with relevant payload.
  
• Open ‘Process and Workflow’ section and search for the triggered process instance.

• Check if the subprocess is executed by the user who submitted the form as ‘Run step on behalf of’ was selected as ‘Approver’.

Use Case- 2: Execute Principal Propagation E2E from One Cloud Foundry environment to another Cloud Foundry environment

Concept:

• User logs in to the cloud application. Its identity is established by an identity provider.
  
• When the application retrieves an OAuthSAMLBearer destination, the user is made available to the Destination Service by means of a user exchange JWT.
  
• The service then wraps the user identity in a SAML assertion, signs it with the SubAccount’s private key and sends it to the specified OAuth token service.
  
• The OAuth token service accepts the SAML assertion and returns an OAuth access token. In turn, the Destination service returns both the destination and the access token to the requesting application.
  
• The application uses the destination properties and the access token to consume the remote API.

Logical Flow of execution:

• Ensure BTP Cockpit access in Source (Sub-account 1) for Configuring destination, download trust certificate.
  
• Ensure BTP Cockpit access in Target (Sub-account 2) for adding trust, spa instance to get Client ID & Secret.
  
• Create, release, deploy a process in Target account. Fetch workflow instance api endpoint and payload from monitor tab.
  
• Create an action using the below json file in Source SubAccount (which will be triggered using the above fetched payload in runtime).
  
• Create destination in source sub-account same way as mentioned in earlier hyperlink.
  
• Add trust configuration in Target Sub-account and add the user’s ID as user with required roles in the trust profile.
  
• Set PP user from source account to the action’s Side Panel.
  
• Create, release, deploy process with the created destination with above action setup in Source account.
  
• Start WF instance with the above fetched payload.
  
• Watch over the execution log in Source account monitor tab.

Logical flow of Setting up outbound communication channel access for the user:

• Create Administrator account
  
• Create Communication user [e.g Client ID & Secret]
  
• Setup communication system using the trust certificate from Source cloud environment.
  
• Specify inbound/outbound communication mode.
  
• Setup communication arrangement, to what service I want access.
  
• Setup Authentication- OAuth
  
• Update destination with OAuth details

Steps:

Configure destination in SAP BTP Cockpit

• Create a business project.

• Create a process and select Run step on behalf of field as preceding approver.

• Configure an action to create workflow instance. This action will be used to call a deployed project instance in another CF environment.

• Release and deploy project with the below destination.

• You can look for principal propagation reference in the deployed model for the activity where user has been propagated to execute the activity on behalf of.

• Create any process in ‘Another environment’ and release, deploy it.
• Note down the workflow definition ID from TRIGGER section in Monitor tab.
• Trigger the process by submitting the trigger form and provide relevant inputs.

• The propagated user from the action’s ‘Run on behalf of’ section has successfully executed the workflow definition corresponding to a deployed process in other CF environment using the configured destination.

Use Case- 3: Principal Propagation from Cloud foundry environment to SAP SuccessFactors

Business user want to propagate the identity of the user mapped for Principal Propagation to an action that invokes API of SAP SuccessFactors.

The post Principal Propagation (Run a Step on Behalf of) in SAP Build Process Automation first appeared on ERP Q&A.

In one of the projects I’m implementing, I needed to process a workflow attachment from within a robotic automation and then I had to create, always from a robotic automation, another document to be consumed as attachment in a form of the same workflow process.

The way an automation can extract an attachment from a workflow is not clearly documented, then I decided to write this blog post in order to share my experience on that topic.

First of all, in order to enable attachment processing in SAP Build Process Automation, the Document Management Service must be enabled in the BTP subaccount and a specific configuration must be performed.

This blog article provides a detailed explanation on how to enable attachments and use them in SAP Build Process Automation.

After completing all the configuration tasks described in the article, now we’re able to create a simple workflow that requires in its first step to upload a document:

And when we start an instance of this workflow process, we can then upload a document:

Before moving forward, we need to understand how the attached document is saved into the Document Management Service (DMS) and how SAP Build Process Automation maintains the link to the uploaded document.

To do that, I used a simple Java frontend that allows to graphically navigate into the DMS (Apache Chemistry).

After logging into the DMS repository I created to save the workflow attachments, I can see that a dedicated folder has been added to the /root, for storing my attachment:

The folder is identified by name and by the cmis Object ID:

Name: yourAttachment_id-1687505271570-12

Object Id: jPYRJg_TzXNQtAmeOYCNuTkYdouICmWxmb15JlVcGJg

Then, opening the SAP Build monitor and looking at the completed workflow, I can see how the link to the the DMS object is maintained in the context of the workflow process:

From the monitor we can understand that the link to the attachment is kept using the object id of the folder. The name of the folder and the name of the document are not available in the context.

Now it’s time to start working at an automation that can extract the document from the DMS repository.

The interaction with the DMS repository occurs thru a set of API.

But we don’t need to spend too much time in understanding the API: in the Store of SAP Build we can find a template named “How to use Document Management Service”:

This template contain examples of automations for performing all the relevant operations needed for working with the DMS. We can just create a project from this template and start using the sample automations provided in the template.

I decided to perform all the activities just reusing the provided examples.

I started creating an automation for extracting an attachment from the DMS and then storing it to a temporary directory (for instance C:\Temp). This automation requires as input parameter a variable of the type Document Folder:

When this automation will be called as part of a workflow process, this input variable will receive the link to the DMS folder in the format it is stored in the context of the workflow, as we’ve seen above.

For extracting the attachment from the DMS, we can use the sample automation named Download document: this automation requires as input the document name, the document path in the DMS and the destination folder to save the extracted document.

But from the information that the automation receives as input, we do not have neither the document name nor the folder name. We have only the object id of the folder.

Then we need to implement some logic for obtaining the required informations (folder name and document name) from the folder object id. Here following all the steps:

1. Scan the content of the /root folder of the DMS repository, using the sample automation named Get folder content. This automation provides as output a list of DMS objects. For each object we have the Object Id, Object Name and Object Type.
   
2. Run a For Each cycle on the list of DMS objects of above, until we can find an object with the id that corresponds to the one received as input. The Object Name of that object is the name of the folder where our document is stored. Let’s call it folder_name and use it in the next step.
   
3. Scan the content of the folder /root/folder_name using the the sample automation named Get folder content, as we did before. Also in this case a list of DMS object is created as output and we expect this list contains only one document, the one we’re looking for.
   
4. Run a For Each cycle on the list of DMS objects of above, until an object with Object type = “document” is found. The Object Name of that object corresponds to the name of the document we want to extract. Let’s call it document_name.

We can now invoke the Download document sample automation, using the folder_name and the document_name obtained with our logic, and setting to C:\Temp\document_name the destination of the extracted document.

The automation I implemented looks like that:

We can add this automation to our workflow:

The input of the automation must be set just selecting the attachment of the previous form.

When running the workflow, the document attached to the initial form is extracted by the automation to the C:\Temp directory of the system where the Agent is running.

The saved document can be processed using other automations in the following steps of the workflow process. For instance, we can attach in the first step an invoice document and then we can extract all the relevant information with a robotic automation.

Now that we know how to use the DMS, we can implement an automation that does the reverse path: it stores a document to the DMS and it makes it available as an attachment to a workflow form.

Assuming we’ve a document saved in the C:\Temp directory of the system where the agent is running, here following the logical steps to be performed:

1. Use the Create folder sample automation to create a folder in DMS /root, assigning a unique name. I usually include the business key of the process and a document identifier.
   
2. Use the Upload document sample automation to upload the document from the C:\Temp directory to the folder we’ve just created in the DMS repository.
   
3. Scan the content of the /root folder of the DMS repository, using the sample automation named Get folder content and obtain a list of DMS objects.
   
4. Run a For Each cycle on the list of DMS objects of above, until we can find an object with the name that corresponds to the name of the folder we created. The Object Id of that folder is the information to be used for making the document available in a workflow form.

The output of this automation must be of Document folder type and we need to compose it adding to the extracted object id the initial string: “spa-res:cmis:folderid:”. Please notice that in your system this string may be different. You can use the SAP Build monitor to see how the attachment’s information are stored in the context of a process.

The automation I implemented for uploading files as attachments looks like that:

This automation can be added to a workflow process and its output can be provided as an attachment to a form.

Now that the logic of the automations for managing the attachment is clear, you will be able to add more features into the workflows you’re developing with SAP Build Process Automation.

For instance:

• the ability to upload a file as a workflow attachment and then to process it using a robotic automation,
  
• the ability to generate a document using a robotic automation and then to make it available as an attachment in a workflow form,
  
• the ability to extract an attachment, manipulate it with a robotic automation and upload it back in the same folder.

The post SAP Build Process Automation: using workflow attachments with robotic automations first appeared on ERP Q&A.

Why would you want to do this?

Creating a quick “Hello World” project is a great way to check that everything is properly configured with your agent while familiarizing yourself with the process building experience.

Requirements to follow this guide

• SAP Build Process Automation
  
• Desktop Agent

Note: Free tier does come with some limitations, but this project can be created with a free tier account. If you would like to create a free tier account you can follow this guide.

1. Open the SAP Build Lobby and click “Create” to start a new project

2. Select “Build an Automated Process” and then “Task Automation”

3. Name your project “Hello World” and add a description then click “Create” to launch the process builder

4. Select your agent version from the list and click “Confirm”. You should see “Local” as a tag for your version. This helps to ensure that everything you create is compatible with that agent version.

5. Give your automation a name and description then click “Create”

Note: The identifier will be automatically created based on the name you provide

6. Before we add any activities to this automation we will need to capture our web page. To start this capture, click on the Create icon on the left side of the screen, then select “Application”

7. Similar to creating the automation, we will now give the application a name and description then click “Create”

8. Open a new browser window and navigate to a website of your choice, for this example I will use google.com

Note: To capture a page it must be open in a separate window as the active tab

9. Return to your project in SAP Build Process Automation and select your web page from the “Web” section of the application capture tool then click “Next”

10. Select “Manual Capture” then click “Capture”

11. Click “Go to Application”

Now that we have captured the page we will capture the search field as an element

12. Click on the search field on the screenshot to select the element then set the name to “Search Field”

13. The capture tool has automatically selected recognition criteria, but we will enhance this by selecting another tag from the “Available Criteria” section on the right side of the window. Select “aria-label: ‘Search’” to add it to the recognition criteria then click “Declare Element”

14. Click “Save” to save this captured application, then return to the automation we created in step 5 by clicking on its tab within the project

15. Select “Screens” to open the list of captured screens then drag the “Google” screen from the right side list into the center of the automation canvas

16. Click on the screen in the canvas then click “Define Screen Activities”

17. Search for “start web page” on the right side then drag the “Start Web Page” activity from the right side onto the screenshot of your captured page

18. Click on the “Start Web Page” activity and then select “Chrome” as the browser in the list of input parameters

19. Click on the search field element within the screenshot then search for “set”

Note: Selecting an element like this will apply contextual filtering to the list of activities so that you only see relevant activities for that element

20. Drag the “Set Element” activity and drop it on the search field highlighted in green

21. Click on the “Set Element” activity then enter “Hello World” in the “value” field in the list of input parameters

22. Click on the search field element within the screenshot then search for “key”

23. Drag the “Keystroke Element” activity and drop it on the search field highlighted in green

24. Click on the “Keystroke Element” activity and open the expression editor for the command field by clicking the pencil icon next to that input parameter

25. Copy and Paste or type “irpa_core.enums.key.Enter” into the expression editor and click “Save Expression”

26. Click “Save” and we are ready to test! To begin the test, click the Play icon in the top left corner

27. Click “Test” and the project will initialize then run

28. Once the automation runs you will see Chrome open to “google.com” and search for “Hello World”

The post How to create a “Hello World” project in SAP Build Process Automation first appeared on ERP Q&A.

Bot opens the excel file in order to get the data and then Bot is opening SAP system and then it opens VA01 transaction (creation of sales order) for data entry and then bot enters the data into the system from excel and saving data.

This blog post will make your manual work easy and will automatically create sales orders. This is very useful in business purpose.

What BOT is doing:

The Structure of a Sales Order:

• An inquiry from a customer consists of one or more items that contains the quantity of a material or service entered in the order. The quantity in a sales order is further divided into business lines and comprises of various subsets and delivering dates. All the valid conditions on these items are mentioned in item conditions. These conditions for an item can be derived via a full condition and can be valid for the entire sales order.
  
• T-Code − VA01 Create a Sales Order

• A new window will open, then you can enter the below details −
  
• Enter the Order Type, below order types are available. Enter the sales organization, distribution channel and division.

• It will open a new window. Enter the following details −
  
  1. Enter Ship-To-Party, Purchase Order and Date.
     
  2. Enter the Required Delivery Date.
     
  3. Enter the item details.

• After this you can click on the save icon at the top. You will get a confirmation message −

INTEGRATING EXCEL WITH SAP:

First thing is fetching all the data from excel and creating Sales order.

secondly, we create our and IRPA Bot in Cloud studio by capturing screens, creating workflows, generating scripts and defining context variables as per requirement and finally it should look like below :

SAP Intelligent RPA Bot Details:

In this application we are capturing all the screens which all are needed for this automation.

WORKFLOW:

How BOT is fetching data from excel:

In the below workflow from Activity 1 to Activity 14.

Open Excel Instance – Mandatory activity to drop when using MS Excel : opens an instance of MS EXCEL. Once you open an Excel Instance, you can use other MS Excel activities.

Open Workbook – Open a workbook referenced by a workbook path. Once opened, use the Activate workbook activity for further usage.

Activate Worksheet – Set the ACTIVE worksheet of the ACTIVE workbook. Once activated, further operations might be possible such as Get Values or Set Values which require an active workbook defined.

Get Values cell – Return(read) the values of a specified cell range in the ACTIVE worksheet.

Range Definition: You need to define the range of a cell from the excel Like A1, A2 etc.

From Activity 4 to Activity 14 you need to define cell range from the Excel.

Custom Script: In Activity 15 we are using custom script it Inserts a step defined by custom JavaScript Code. We are adding custom script for opening SAP by giving the credentials.

JavaScript Code for defining the Input Parameters:

irpa_core.core.shellexec(‘sapshcut.exe’, ‘-system=’ + System + ‘ -client=’ + Client + ‘ -user=’ + UserName + ‘ -pw=’ + Password);

WAIT: Activity 16 It is used for a given delay (expressed in ms) between two activities for example for example. It can be useful if some User Interface elements cannot be detected or if some User Interface interactions are too fast . By adding wait , the overall automation duration may increase.

From Activity 17 to Activity 19:

In this we are defining the screen activities by capturing all the screens from SAP application .

Maximize Window (GUI Frame): In Activity 17 we are defining maximize a frame window in the background.

Set Element: In Activity 18 Set the value of a User Interface Element

Click: In Activity 19 execute a ‘click’ action on a button.

From Activity 20 to Activity 25:

Wait(Screen): In Activity 20 we are using wait screen wait until a screen is present and then call a callback. If the screen already exists, the callback is called immediately.

From Activity 21 to Activity 24–

We are setting the element of a User Interface Element from the excel by using this expression Step4.returnedValues (From Step 4 we need the data from excel). Same we are doing for other set elements

Activity 25: We are using ‘CLICK’ activity.

Activity 26 to Activity 33:

In Activity 26 we are using Wait(Screen) and then we are Setting elements from Activity 27 to 33 accordingly from the Excel and then we are using click (defined activity in the application) as SAVE.

Activity 35: In this Pop up screen of SAP we are using CLICK as an Activity.

Activity 36: In this pop up screen we are using again CLICK activity to save the document.

Close workbook – In Activity 37 we are using Close Workbook (Closing the active workbook).

Release Excel Instance – In Activity 38 we are using this activity release an instance without closing an application.

The post Sales Order Creation with SAP Intelligent RPA| Integrating SAP with Excel first appeared on ERP Q&A.

This blog will be helpful for those who use Google Workspace products as their office suite and would like to automate them. Let’s look at a few most helpful activities under the modules for Gmail, Google Sheets and Google Drive.

Prerequisite:

Before using the activities provided by Google Workspace SDK, SAP Build Process Automation must be authorized to access the Google account.

Dependencies:

To automate the Google Workspace products, Google Authorization SDK and Google Workspace SDK must be added as dependencies to the project in Cloud Studio.

Gmail:

Gmail is an email service provided by Google.

The SDK provides the activities for sending an email, searching for emails, reading an email, modifying the labels of an email, and replying to the email.

Let’s understand a few of these activities in details:

Read Email (Gmail):

This activity reads an email and downloads the associated attachment(s).

This activity can be used by looping over the list obtained as output of the “Search Emails (Gmail)” activity and the “messageId” of each element in the list can be fed to this activity to read the contents of the email.

Input parameters:

• messageId: Message ID of the email to read.
  
• location: The attachments present in the email can be downloaded to either the local file system or to Google Drive by setting this parameter to “fileSystem” or “drive” respectively.
  
• pathOrDriveId: Based upon whether to download the attachments to local file system or Google Drive, the “pathOrDriveId” parameter can be set to either the path to a location on the local file system or the URL to a Google Drive location respectively. By default, the ‘Downloads’ folder of the system is used if ‘fileSystem’ is selected, and ‘My Drive’ is used if ‘drive’ is selected as location.
  
• markAsRead: Set this true to mark the email as read.
  
• timeout: Timeout for the activity in ms. The default is 30,000 ms.

Output parameters:

• messageDetail: JSON which contains the details of the read email like from, to, cc, subject, body, attachments, etc.

Send Email (Gmail):

This activity sends an email.

Input parameters:

• gmailParameters: It is a data type comprising of:
  
  • to: List of direct recipients of the email.
    
  • cc: List of carbon copy recipients of the email.
    
  • bcc: List of blind carbon copy recipients of the email.
    
  • subject: Subject of the email.
    
  • body: Body of the email.
    
  • isHtmlBody: This is set to false by default and it means that the body will be treated as plain text. However, it is possible to set this to true and send HTML content as part of the email body.
    
  • attachments: List of attachments.
    
    • attachFrom: The attachments could be included either from local file system or from Google Drive by setting this parameter to “fileSystem” or “drive” respectively.
      
    • filePath: Based upon whether to include the attachments from local file system or Google Drive, this parameter can be set to either the path to the local file system or the Google Drive file ID respectively.
      
• timeout: Timeout for the activity. The default is 30,000 ms.

Google Sheets:

Google Sheets is used to create and edit online spreadsheets.

The SDK provides the activities for creating/renaming a spreadsheet, adding/deleting/renaming/hiding/copying/moving a sheet within a spreadsheet, fetching list of spreadsheets and their details, setting/getting values, importing Excel file as a Google Sheet, etc.

Let’s understand a few of these activities in details:

Get Cell Values (Google Sheet):

This activity reads the values from the specified spreadsheet.

Input parameters:

• spreadSheetId: ID of the spreadsheet to read.
  
• range: It is a data type comprising of:
  
  • sheetTitle: Title of the sheet to read.
    
  • startRange: Address of the cell in A1 notation to start reading the data from.
    
  • endRange: Address of the cell in A1 notation to end reading the data at. Get Last Row (Google Sheet) and Get Last Column (Google Sheet) activities can be used to get the last populated row and column respectively.
    
• majorDimension: It can be set to “rows” or “columns”. If it is set to “rows”, then the output data will be a 2D array with row as the major dimension.
  
• valueRenderOption: It can be set to
  
  • “formatted” – the output data will be same as the formatted value in the spreadsheet,
    
  • “unformatted” – the output will be raw data,
    
  • “formula” – the output data will be the formula and not the value.
    
• timeout: Timeout for the activity in ms. The default is 30,000 ms.

Output parameters:

• cellsData: JSON with “values” property as a 2D array.

Set Cell Values (Google Sheet):

This activity sets values in the specified spreadsheet.

Input parameters:

• spreadSheetId: ID of the spreadsheet to update.
  
• range: It is a data type comprising of:
  
  • sheetTitle: Title of the sheet to update.
    
  • startRange: Address of the cell in A1 notation to start writing the data at.
    
  • endRange: Address of the cell in A1 notation to end writing the data at.
    
• values: It accepts both single-dimensional and 2-dimensional array. In case of a single dimensional array, it accepts an array of CSV strings [‘1,2,3,4’, ‘A,B,C,D,E’] in which each string represents major dimension with comma as the separator. In case of a 2-dimensional array, each array represents a row or column based on major dimension. For example [[1,2,3,4], [‘first’, ‘second’, ‘third’, ‘fourth’]].
  
• majorDimension: It can be set to “rows” or “columns”. If it is set to “rows”, then the “values” will be processed as an array with row as the major dimension.
  
• valueInputOption: It can be set to
  
  • “userEntered” – the data will be written with the destination formatting,
    
  • “raw” – the raw data will be written.
    
• timeout: Timeout for the activity in ms. The default is 30,000 ms.

Output parameters:

• isDataUpdated: It is set to true if the data was set successfully.

Google Drive:

Google Drive allows users to store files in the cloud and share them. It has a default drive called “My Drive” and it is also possible to create shared drives.

The SDK provides the activities for fetching the details of files/folders, and uploading/downloading/sharing/moving/renaming a file.

Let’s understand a few of these activities in details:

Download File (Google Drive):

This activity downloads a file from Google Drive.

Input parameters:

• fileId: The unique ID of the file to download.
  
• localFolderPath: Parameter to specify the folder in which the file should be downloaded. The ‘Downloads’ folder in the file system is used by default.
  
• name: The name to which the downloaded file should be renamed to.
  
• timeout: Timeout for the activity in ms. The default is 30,000 ms.

Output parameters:

• MetaData: The metadata of the file that was downloaded.

Upload File (Google Drive):

This activity uploads a file to Google Drive.

Input parameters:

• filePath: Path of the file to be uploaded.
  
• name: The name to which the uploaded file should be renamed to.
  
• description: A short description of the file.
  
• parentID: The ID of the parent file or folder to upload the file to. If not set, the file will be uploaded to ‘My Drive’ by default.
  
• readOnly: If set to true, the file will be in read-only mode.
  
• writerCanShare: If set to true, only the users with the writer permission can modify the file’s permissions. This parameter is not applicable for files in shared drives.
  
• keepRevisionForever: Set this parameter to true to deactivate the default retention policy in Google Drive. By default, Drive empties files from trash 30 days after they’re moved to trash.
  
• copyRequiresWriterPermission: Set this parameter to true to disable the options to copy, print, or download the file for users with reader and commenter permissions.
  
• timeout: Timeout for the activity in ms. The default is 30,000 ms.

Output parameters:

• Metadata: The metadata of the uploaded file.

The post Automating Gmail, Google Sheets and Google Drive with SAP Build Process Automation first appeared on ERP Q&A.