Neue Agent Architektur

Webinar Integration Agent – Neue Architektur am 24.09.2020

- Webinar -SKYVVA Integration Agent neue Architektur

Donnerstag 24. September 2020 | 15:00 - 15:45 Uhr CEST

Wir laden Sie herzlich zu unserem Webinar –  SKYVVA ANY Connect –

Eine neue schlanke, offene und erweiterbare Architektur

Wie wir alle wissen, ist Salesforce CRM eines der gefragtesten CRMs in der heutigen Zeit.
Die Integration von Drittsystemen in Salesforce ist meist nicht nur hilfreich, sondern geschäftliche Notwendigkeit. Die verschiedenen Komponenten der IT-Infrastruktur müssen miteinander kommunizieren können, ohne dass Daten verloren gehen.
Dies ist eine Voraussetzung für ein erfolgreich funktionierendes Salesforce CRM-System.

Vor diesem Hintergrund veranstalten wir ein Webinar zum Thema ” SKYVVA ANY Connect – Eine neue schlanke, offene und erweiterbare Architektur”.

Wir freuen uns auf Ihre Teilnahme.

Ihr Aspara-Team!

Erfahren Sie mehr in diesem Webinar über:

  • Open and Extensible architecture for Salesforce Connectors
  • New available connectors for event-driven based integration
  • File connector enhancement to support file incoming event
  • Lightweight connector framework e.g. not a overweight enterprise bus
  • Q & A

Release Spring 2.45

Release Spring ´20 SKYVVA – Official Version 2.45


Spring ´20 Release

Das Spring ´20 Release ist in der SKYVVA Official Version 2.45 bald verfügbar. Das Release kann in Kürze über die nachstehenden Downloads für Ihre Sandbox oder die Produkts-/Entwickler Organisationen aktualisiert werden:

  • Sandbox Organisationen
  • / Free Version
  • Produkt-/ Entwickler Organisationen
  • / Free Version


Neue Features

Die Highlights des Spring ´20 Release finden Sie in der folgenden Kurzübersicht:

  • New adapter for example SAP PI/PO to use v3 outbound processing and to replace the existing one such as SFDC2SAPPI adapter which uses v2
  • Enhanced mapping tool to support hierarchical mapping
  • Import different file format such as xsd, json schema, WSDL and openAPI to generate message type
  • Enhance Message Monitoring to support Event- and API Monitoring
  • Export xsd and wsdl from message type
  • New Agent with Camel
  • Old Agent using https
  • Agent Control Board for old and new
  • Adapt CDC to use v3 outbound processing
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Daten Integration SKYVVA Lösungen

Release Winter ´20 SKYVVA – Official Version 2.44


Winter ´20 Release

Das Winter ´20 Release ist in der SKYVVA Official Version 2.44 ab sofort verfügbar. Das Release kann über die nachstehenden Downloads für Ihre Sandbox oder die Produkts-/Entwickler Organisationen aktualisiert werden:

  • Sandbox Organisationen
  • / Free Version
  • Produkt-/ Entwickler Organisationen
  • / Free Version

Neue Features

Die Highlights des Winter ´20 Release finden Sie in der folgenden Kurzübersicht:

  • New version V3 of inbound and outbound processing
  • Enhanced mapping tool to support hierarchical mapping
  • Support Salesforce REST and Bulk Query to retrieve large volume data
  • Enhance Message Monitoring to support Event- and API Monitoring
  • Data Loader support hierarchical XML
  • SKYVVA Bulk and Batch Mode support the new version V3 of Inbound Processing
  • Workflow Support New Version V3 of Outbound Processing
  • New Formula Functions
  • Re-Order by Sequence Number for Repository and MessageType
  • New Version of the SOAP and REST Adapter
  • Acknowledgment Handling

Bug Fixes

  • Export MetaData Provider are Missing Fields
  • Get Error on Edit and Delete Repository
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
SAP Salesforce Integration

SAP Salesforce integration options and variants

SAP is the world-leading ERP software offering for all size of enterprise the right business solution. It is your digital back tier core. On the other side, Salesforce is your digital front tier core for your customer success. Business processes starting from your front tier e.g. Salesforce and ending at your back tier e.g. SAP create a unique business value chain which is essential for your company success. They can only work if the functional interaction and data synchronization smoothly work together. Deep and native integration is, therefore, the key success factor. But are you aware of how the solution suite can integrate into which way with Salesforce?

Before going into the various of SAP Salesforce integration options let us have a look at the business solution landscape of SAP as of today.

SAP business solution suite

Starting from R/2 in the earlier sixties SAP has launched the R/3 suite in the eighties which follows the Client/Server paradigm. In this range, we have SAP R/3 with the following version 3.1, 4.0 and 4.7 which is called R/3 Enterprise. Later there is ECC 6.0 or SAP ERP 6.0. These are the on-premise version of the SAP-ERP Business Suite. For small size business SAP has launched SAP Business One which now exists in on-premise as also in the cloud version.

Most used SAP ERP as of today is the ECC 6.0 or SAP ERP 6.0. New release and functionality enhancement are coming through SAP enhancement packs. Since 2015 SAP has launched a new suite called S/4HANA which come in two flavors e.g. on-premise or Cloud. It is based on the SAP innovative in-memory database engine and now become a populate migration path of an existing customer. Besides these main ERP suite branch SAP has other edition called SAP Business ByDesign which is a cloud offering and the SAP Business All-In-One which contain a reduced functional package as the full-blown SAP ERP 6.0 Suite.

Besides the ERP business suite SAP also provide integration product launched in earlier 2013 which call SAP-XI (Exchange Infrastructure) 2.0/3.0. The successor release is the SAP PI (Process Integration) and was renamed to PO (Process Orchestration). The latest version of SAP-PI/PO is as 7.50. Since the cloud paradigm become widely adopted SAP has launched a cloud version called SAP CPI (Cloud Platform Integration) and has now started the open initiative of SAP Cloud Platform Open Connectors. With the Cloud Open Platform Connectors SAP provides a huge number of different connectors like facebook, google, PayPal, etc.. to support mot than 100+ connectors.

You could have one of such SAP software stack and need to integrate with your Salesforce for a SAP Salesforce Integration. So how can you handle that many integration variants? Which technology to use in which case?

SAP Salesforce Integration variant

The integration of technology and possibility in SAP eco-system is huge and complex. To find the right technology you need to be an expert because there are too many modules, stack, and protocol to consider. You might don’t have time and the technical skill to implement such an integration tool and handle the different protocol conversion and data transformation yourself. With the SAP Connect of the SKYVVA integration service layer, you are able to connect to the different SAP component neither it is the middleware or the business suite application.

SAP Salesforce Integration Blog

It makes sense to use specific and best-fit technology and protocol for each solution variants. For example, if you need to connect to your SAP-ERP ECC 6.0 only and you don’t have a middleware then it makes no sense first to buy a middleware. In this case, you can use the variant with the SAP-ERP Connect without using middleware in between as an integration mediator. This would be the fasted and optimized way to integrate Salesforce with your SAP-ERP ECC 6.0.

SKYVVA has built-in adapters on both platforms to leverage the best in place and natïve technology to handle the integration. It supports in case of SAP-ERP the native protocol such as BAPI/RFC, IDoc, and ABAP-Proxy. You can keep the investment, speed up your development by reusing the existing scenario where you have used BAPI and IDoc. If you want to use the latest technology such as Web service with REST and restful approach SKYVVA SAP connect can supports it as well.

The above picture gives you an overview of which option and variations you can choose to integrate Salesforce and SAP. SKYVVA offers different way based on the SAP business suite component used at your end. If you use on-premise middleware as the SAP-PI/PO then you can go with the SAP-PI/PO Connect. If you are using the cloud version e.g. SAP CPI then you can use the SAP CPI connect. SKYVVA provide on the SAP side the native adapter to utilize the most advanced and built-in technology available on the platform. Thus creating fast, reliable and optimized code for the integration demand.

Here are the available SAP Connect:

  • SAP CPI Connect
  • SAP PI/PO Connect
  • SAP S/4HANA Connect
  • SAP Business One Connect
  • SAP Business ByDesign Connect
  • SAP All-in-One Connect
  • SAP ERP Connect

On-premise and Cloud integration technology

We have passed the day where we have only to deal with the on-premise system and installation. New disrupted business required definitely the cloud technology and thus we have to handle the different technology separately to consider and reflect their different particularity. Cloud technology is different from op-premise technology because the paradigm is totally changed.

On-premise and Cloud integration technology

SAP provides various interface technology from its first release which based on RFC and later evolved to become BAPI which follow the object encapsulation principle and follow the interface contractual design pattern. For asynchronous communication pattern often IDoc is used because it is integrated into the application as SD, MM, FI, etc. These technology based on the proprietary RFC which based on the CPIC protocol implemented in the C-Kernel of the underlying SAP basis stack. 

With the emerging of the internet technology, the standard HTTP protocol was introduced to the abap kernel stack and thus new programing model like ABAP-Proxy was created to support open communication with the internet and using a lightweight protocol for better performance.

This technology is used by SKYVVA component sitting inside the abap stack of the SAP ERP 6.0, S/4HANA and SAP Business All-in-One.  For integrating to the SAP Business One the HANA Service Layer is used to connect with the available API. These are the technology which is used to build a smooth and seamless integration to the on-premise SAP application suite.

On the other side thinking for the future SAP has launched the last few year’s different cloud-based products such as Ariba, SuccessFactors, Hybris, etc. and released new SAP business suite version such as S/4HANA Cloud, SAP Business One Cloud, and SAP BusinessByDesign which support the cloud deployment option. 


SAP Cloud Connect

Common to all cloud application is that they provide APIs based on the SOAP or RESTful technology and design principle. Swagger, openAPI 3.x and OData are emerging standard protocol to define and described the API while for soap-based web service, WSDL 1.1 or 2.0 are used. Knowing and building on this technology is crucial to conform to the emerging standard technology in the cloud to cloud integration. When we come to the RESTful web services OAuth 2.0 for the authentication are the standard protocol to use over the old-style username and password basic authentication.

Therefore merging the technology and using the same for any kind of integration to the SAP on-premise and cloud application suite will not make the most use of the strength and advantages of certain technology. SKYVVA provide for the on-premise world dedicated and specific connectors to leverage the SAP proprietary technology available. For the cloud world, you can use the SAP cloud connect to leverage the standard technology for cloud-based application integration.

Following we are going to discuss each integration variant in detail.

SAP ERP Business Suite

SAP ECC 6.0 or ERP 6.0 uses the abap stack. The interface technology is proprietary and is based on the CPIC library in the SAP kernel. Based on that the RFC protocol is used to build the foundation of the BAPI/RFC and IDoc. For each SAP module as SD, MM, CO, FI, etc. there are thousands of BAPI for almost any kind of business transaction. Furthermore, the customer can create their own RFC. Where BAPI/RFC is used for the synchronous communication IDoc is used for the asynchronous data transfer. IDoc is built-in into many SAP module and tightly integrated for example in an ALE and change point scenario.


SAP ERP Business Suite

Those interface technologies are proprietary and don’t not compatible with Salesforce interface technology which is based on the internet standard using web service based on the HTTP protocol. Salesforce understands non of the SAP communication protocol and thus incompatible to each other which means that they cannot connect to each other easily. To be able to do you need to convert the old and proprietary SAP RFC protocol to the internet standard.

SKYVVA provide a connector inside the SAP ECC as a bridge to convert the proprietary SAP protocol to the internet standard so that the Salesforce SOAP and REST API can be used. It uses the built-in ICM (Internet Communication Manager) component from SAP to implement the internet protocol. It is able to use the standard soap and rest technology provided by the SAP Gateway. 

Note that to have an additional functionality needed for an enterprise-class integration SKYVVA has added a service layer into the Salesforce platform. To understand the need and benefits of the SKYVVA service layer on the Salesforce side refer to the following blog:

S/4HANA on-premise

Since its launch in February 2015, S/4HANA becomes a significant path for the customer who is still using SAP ERP 6.0 and thinks to move to the new technology supporting by the HANA database. In fact, the application layer is still based on the core abap stack but has been enhanced to support the new and latest technology in term of performance and cloud technology. From the function perspective, it offers a simple and lightweight module for some business area and in contrast to the SAP ERP business suite, it does not cover a monolith block of everything.

S/4HANA on-premise SAP Salesforce Integration

S/4HANA on-premise installation is from keeping the same technology stack as the SAP ERP business suite and thus the integration and interface technology remain but got some improvement. SKYVVA has adapted the SAP-ERP connect to support native element and enhancement of S/4HANA and thus provide a native component for the Salesforce integration.

S/4HANA is not only changing the underlying database to use the in-memory approach but from the deployment perspective, it has followed the cloud computing paradigm by providing it as the cloud option as well. This is the biggest update in SAP’s ERP strategy and platform and enables the customer to move into the new cloud computing or stay on the on-premise world.

S/4HANA Cloud

Regarding the technology stack SAP S/4HANA covers different type of APIs such as web services based APIs (OData, REST and SOAP), traditional SAP APIs (BAPIs and IDOCs) and CDS views which can be exposed as OData services. The SKYVVA S/4HANA Connect uses the web API technology based on RESTful architecture. From the S/4HANA perspective, SKYVVA provides REST APIs to integrate seamlessly to the SKYVVA service layer. 

SAP Business All-in-One

SAP Business All-in-One is a special offering which now is not promoted by SAP anymore. It flows into the product area of Small and Medium Enterprises (SME) and was intended to deliver a pre-packaged and industry-specific bundle of SAP-ERP. It is based on the SAP NetWeaver stack and thus leverages the same abap platform like the SAP-ERP 6.0. The integration technology SKYVVA provide here is similar to the SAP-ERP 6.0 Edition. Therefore refer to the integration option above at the SAP ERP Business Suite.

SAP Business ByDesign

SAP Business ByDesign is a cloud offering and now under the category of SAP Cloud ERP. It was developed by SAP for small and medium-sized businesses in mind which are based on SAP’s “best practices”.

SAP Business ByDesign

For integration purpose to external system SAP Business ByDesign provide a set of APIs including OData endpoint to seamlessly execute the business operation on the given object. For example, the sales order API allows to create and change a sales order and its document flow. The SKYVVA ByDesign Connect use the web API technology to integrate Salesforce with the SAP Business ByDesign.

SAP Business One on-premise

For data exchange in SAP Business One provides these two interfaces, so-called Application Programming Interfaces (APIs) are provided:

  • SAP HANA Service Layer API Technology
    The next generation API for the digial business allowing you to create lightweight mobile apps consuming SAP Business One data and services using open core protocols such as HTTP and ODATA.
    This technology is only available for SAP Business One, version for SAP HANA.
  • SAP Business One DI API
    The DI API contains objects and methods that enable developers to read, write, update, and remove data objects on database level.
    This DI API is available for SAP Business One on MS SQL, too.
SAP Business One on-premise

SKYVVA support the latest technology using the Service Layer to connect from Salesforce through the API to the Business One Sever. All available API from SAP Business One can be used to create, read, update and delete application object. Business application function can be executed through the SOAP interfaces.

SAP Business One Cloud

SAP Business one can run on cloud which simplifies the hard- and software landscape within your company. There is two option which you can go with cloud deployment. You can either get your own license and your SAP partner host the service for you or you can rent on a monthly basis from SAP. Regardless for which deployment option you will go the underlying basis is the same which means that the integration technology is the same.

SAP Business One Cloud

On the cloud layer, there is the same component and technology used for integration as in the on-premise deployment. Here the SAP HANA service layer can be used to provide REST, SOAP and OData services to access the business functionality in the form of APIs. SKYVVA Business One Connect can use to integrate to SAP Business One as a cloud-to-cloud approach.

SAP-PI/PO (Process Integration/Process Orchestration)

SAP-PI/PO provide you a middleware to handle all kind of integration which is mostly used to integrate to your SAP software landscape and other on-premise application. It provides a various adapter to connect to the business system and gives you the power to design, develop and run integration scenario within your on-premise landscape.

SAP-PI/PO SAP Salesforce Integration

The integration to and from SAP-PI/PO is done use the SKYVVA connector component sitting directly on the J2EE-Engine of the SAP-PI/PO engine. This component handles all connection requirement to and from Salesforce and offers a specific Salesforce feature which is available as the additional layer on the Salesforce side. Additional value is for example to have the

  • Message monitoring
  • Message reprocessing
  • Alerting
  • Error handling

on Salesforce to give you more operational tool to handle your daily integration problem. From the technology standpoint, the native component is talking together to get the best possible integration speed you can ever thing. There is no something in between to impact the integration flow like protocol and format conversation because of the different techniques of the different platform. SKYVVA component uses the native technique and programming library on each side.

For the common integration use case like Account, Contact, Quote, etc. SKYVVA provide a ready to run so-called integration App on SAP-PI/PO which easily can be deployed and adapted to the business requirement quickly. This will reduce your development cycle and save cost and effort considerably.

SAP CPI (Cloud Platform Integration)

The SAP CPI is the cloud integration tool offering from SAP to follow the cloud computing paradigm and provide the latest cloud technology for their integration solution suite. As of SAP-PI/PO, it provides almost the same functionality and adapters and is compatible in term of for example the mapping engine. The SAP-PI/PO mapping can be reused in the CPI runtime.


SKYVVA provide in a similar way a native connector developed with the Adapter SDK from SAP and thus leverage most of the technology possible. It provides the inbound and outbound adapter to handle both communication direction, support streaming, and BULK API to handle the special requirement for Salesforce integration.

The adapter can be deployed to your CPI tenant as a third-party adapter and there is also pre-define integration app available like for the SAP-PI/PO edition.

SAP Cloud Platform Open Connectors

With the latest offering for the cloud, variant SAP has announced to have the open connectors which provide 100+ connectors for different use cases. One of the connectors available is the Salesforce connector which uses the Salesforce standard API to provide the integration services. The issues with any standard Salesforce adapter is the limitation which comes with the API connectivity approach. For some integration requirement, it is too basic and low level just to have the ability to do the CRUD operation. Refer to this blog to overcome this issue.

SAP Cloud Platform Open Connectors

Therefore SKYVVA has added the so-called API Connect to provide SKYVVA value-added API to the external system to be able to connect to the SKYVVA service layer to get all the value-added feature and capability missing with the standard Salesforce connector. With the additional service layer on the Salesforce side, you will add more quality and save significant cost in your daily interface operation.

Summary SAP Salesforce Integration

Now you have seen the possible solution landscape used within the SAP environment which is the most common one you will have yourself or will see it. The SAP Salesforce integration is based on the SAP common technology but has it’s different specific and thus SKYVVA provides for each option a dedicated connector to be able to handle their technology, protocol, and data format in an optimized way. 

The connector is developed in SAP native technology to be able to use all available tool, technique, and protocol. Unlike the other solution on the market, the direct and native approach doesn’t create any friction between the connected system. It is the fastest and optimized way you can think for an SAP and Salesforce integration. If you need performance, reliability, directness, lightweight and cost-effective solution without having to buy another middleware then this is the option to go.

What is your SAP integration need? To which system do you want to connect? Is there something missing? This blog covers the most common SAP system used at the company of all size and nowadays with the cloud option there is a seamless way to connect Salesforce to the SAP cloud direct as the cloud-to-cloud connect without having a middleware in between. 

There is simply no need for an intermediator like a middleware (middleware will cause unnecessary complexity) to have the deep and direct digital connected platform which is essential and crucial for your business. Go the new and direct cloud-to-cloud connect approach to disrupt your new business and be ahead of your competitor for Salesforce-centric solution-based processes.

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Summer ´19 Rlease SKYVVA

Release Summer ´19 SKYVVA – Official Version 2.43


Summer ´19 Release

Das Summer ´19 Release ist in der SKYVVA Official Version 2.43 ab sofort verfügbar. Das Release kann über die nachstehenden Downloads für Ihre Sandbox oder die Produkts-/Entwickler Organisationen aktualisiert werden:

  • Sandbox Organisationen
  • / Free Version
  • Produkts-/ Entwickler Organisationen
  • / Free Version

Neue Features

Die Highlights des Summer ´19 Releases finden Sie in der folgenden Kurzübersicht:

  • Response mapping using message type for API integrate Synchronous
  • Enhance workflow view because of the hierarchical interface
  • Configure the whole integration to SAP (direct) from Salesforce
  • Send Salesforce CDC Change Event to the receiver through our outbound interface
  • The new version of integrating to speed up the processing
  • Simplify Error handling for asynchronous outbound -BAPI to ABAP-Adapter
  • Enhance operation query to use free define target structure for mapping
  • CDC – Support to sent message in case of Undelete
  • Conversion table as mapping formula
  • Activate and Deactivate the adapter
  • What to do with the failed message with the same external Id?
  • Publish Event using SKYVVA interface
  • Allow ping for soap, rest and all others adapter
  • SOQL Statement for the outbound interface can be empty
  • Display Columns Tree of the hierarchical XML in Manual Load
  • Make Change on Stop By Admin with Push Data In Batch Processing
  • Enhancing the MessageType validation for easier use
  • By-passing message layer in any case
  • New field External Message Id in the massage table
  • Add new field ‘Comment’ on the message monitor to filter the comment field
  • Option to exclude Interface name on the message search page
  • Message monitoring- Comment field in a search filter to search message by comment
  • Related To link on the message monitor
  • Filter scheduler by its status
  • Add new filter on the license tab key to select users
  • Separate Batch and Bulk between Processing and Reprocessing on Functional Category
  • Operation type = Apex Class to execute the post-processing after the mapping step
  • Send Salesforce CDC data change to the external client without having the CometD support
  • Using apex trigger to consume the CDC event or platform event to create CP records
  • Add filter condition on a lookup field in Metadata
  • Add the ID of parent interface into the parent interface field in child interface
  • Show all messages from the basket in History Basket
  • Create a link for the failed message in pending message in the message detail view
  • Change section Message Processing Step to Custom Plug-in to SKYVVA Processing Block
  • Create new fields in Agent Setting and Agent Property
  • Create MsgType base on the Open API 3.0 file format
  • Implement SKYVVA Trigger to support with the lightning version by using Quick Action
  • Integration and Interface Overview tab on Agent Control Board with LWC

Bug Fixes

  • Handling soap fault messages
  • Message type which is constructed using Salesforce sObject is not shown correctly in the mapping editor
  • IStructure Repository and MessageType’s child table should only show Child only
  • Add additional property to the JSON schema and open API 2.0 parser to support the array and required node
  • Got error on Apply Filters scheduler on Admin tab
  • Fix bug on the XSD and JSON Schema parser where it should create Istructure instead of MessageType
  • Long Comment sent from SOAP UI doesn’t work
  • Named Metadata Provider file like its name in produce
  • Unable to create SFDC2SAPPI adapter with full URL
  • SKYVVA__PARENTID generate incorrect in Target Path
  • Not allow show subinterface in Interface Name picklist
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Blog Anwendungsbereich Middleware Connect

Why using a middleware only for Salesforce integration is not enough?

Salesforce is your digital front tier core for your customer success and you integrate ERP system such SAP, webshops such as Amazon or eBay, payment systems such as PayPal, social media such as Facebook or LinkedIn, legacy data pool such as database, file or FTP to and from your Salesforce to get a connected and non-disrupted customer experiences using a middleware. It works as design but one day you realize that some data are missing which has been sent from the middleware. You are not sure which data was arriving on your Salesforce side and you ask yourself “Where can I see the data which was sent by the middleware?”. You are not asking the question as “Which data was sent from the middleware?” because the middleware provides you a nice monitoring feature to see data leaving the middleware platform.

Middleware any to any

You’ve connected an HR and billing system to your Salesforce and need to keep data history for your auditing department to prove the evidence for a government security and auditing check happened regularly at your company. For such an auditing process data on one side e.g. sender (middleware) is not sufficient and do not fulfill the government auditing standard and they request you to provide the other side e.g. data that arrive on the Salesforce side. How are you going to provide such logging and tracing of the historical data on the Salesforce side?

Since you use a middleware you have a nice feature to alert in case the message get failed while get sent to Salesforce. You love this feature because you don’t need to actively look every five minutes on the monitoring at your middleware. One day you realize that some of the alerts contained strange technical error text as

“java.lang.StringIndexOutOfBoundsException: String index out of range: -1

            at java.lang.AbstractStringBuilder.substring(

            at java.lang.StringBuilder.substring(

            at java.lang.AbstractStringBuilder.subSequence(”

But you would expect a clear business error telling you something like “Quote xx cannot be posted due to invalid sales area code”. Which of the error text would you like to see?

Such situations can and will happen one day with your Salesforce integration and when it happens are you going to ask the same question instead of providing a solution to fix that? Read the following essay when you want to see the solution and answer.

How Middleware integration looks like

Let’s have a look and understand the Salesforce integration using middleware. To connect to Salesforce the middleware provides a technical connector which is able to invoke and consume the SOAP or REST API of Salesforce standard API. It uses the request/response pattern which is common to API principle and each call waits until the operation on the Salesforce side finish. This is the nature of synchronous API call which follows the tight coupling architecture pattern. With the standard Salesforce API, you can do great the basic four so-called CRUD operation meaning that you can create, read, update and delete a sObject.

Middleware Integration

Besides these four basic CRUD operation, there are no other additional capability and feature available on your Salesforce side. Some question you might ask is how you can do more than those four basic CRUD operation? Your integration, for example, needs to update a contact where it was changed on your ERP system such as SAP. But before the update, you need to check the assignment rule that the contact has the status ‘Released’ and is maintained by the sales agent group called ‘inside sales’. After you have updated the contact you want to do some cleanup operation to change the status to ‘Synchronized’. This means that you need more than only update the contact with some data which have been changed from SAP. You need pre- and post business logic to execute alongside the integration. How can you do such pre- and post additional business logic?

What is missing?

Because your Salesforce with all the apps from third-party vendors and your own app becomes such an important digital front tier layer for your custom success you want to have an enterprise-class integration which goes beyond the API connected approach. Refer to our other blog to understand the limitations and impact of the API only connected approach

API connectivity

For enterprise-class integration, you need more than just the API connectivity. You might need to add business logic to your simple API integration. You might need monitoring, alerting and an easy way to handle errors on your Salesforce side. You might come to some urgent and emergency situation where the middleware is not alive and thus cannot resend the message to be processed on time. In this case, it would be a great help if you can modify data as you need on the Salesforce side and do a reprocessing. Furthermore, from the technical architectural standpoint, you need also a loose coupling pattern to handle mass data transfer which can only be done by using asynchronous API.

Why a decoupling services layer is needed

The additional value-added services mentioned above are needed for an enterprise-class integration which is not available on the Salesforce platform and which middleware cannot offer. To provide such services a decoupling layer is needed on the Salesforce platform which can stage the incoming data as messages for processing at any suitable time. Since no such a layer exists on the Salesforce platform SKYVVA has created such a layer to provide all the functionality like described in the above diagram.

SKYVVA Service Layer

The service layer is the technical basis for any functionality to allows the API processing to be executed in an asynchronous way. An asynchronous pattern is a crucial factor in the integration architecture because it provides the decoupling capability and independence of operation and thus is lose coupled. Lose coupled operation, on the other hand, has a big advantage and architectural benefits against the tight coupling pattern because it releases the client immediately from getting blocked. The client has not to wait until the invoked operation is finished. Less dependency and lose coupling create less cohesion and binding of interconnected operation which in term of resource consumption and performance is the best approach available for integration principle.

The loose coupling architectural style is just one of the outstanding feature resulted from having a service laver on the Salesforce side. Further benefits you have is, for example, the capability to shift the processing of the messages to a later time. Real-time and processing everything immediately sound great and fit best to some use cases where the user is waiting for a prompt response. But when coming to enterprise integration where the end-user is not involved you don’t need always a prompt response because it is useless and simply not needed.

Imagine that you have a webshop and you have to update on a daily basis millions of product prices. How can you do that at real-time? This is technically not possible doing in real-time because you will hit many Salesforce governor limits like the number of API calls per 24 hours, the available operating system thread to handle such a mass request and finally you will impact the performance of your Salesforce Org. and thus breaks the performance for your end-users in the business working hours.

In such a situation where it is sufficient to have the updated price of all product in the morning, you can use batch and bundling technique to send packages of for example 10k of price updates and process the messages in the night starting from 10:00 pm every day. Such scheduling is easy to configure using the scheduling functionality of SKYVVA. The benefit you get is shifting the processing of mass volume data into a time which is suitable for such a kind of data processing. Without a service layer like provided by SKYVVA, such a use case can simply not be handled by the Salesforce standard by just using the API connected approach only.

With a service layer on the Salesforce side, many additional value-added features like described above will be available to support you in your daily operation and maintenance of the integration scenario. The following description will show some important additional value-added feature in more detail.

Additional services you simply need

The various value-added feature will help and simplify the maintenance and operation of your daily integration with your Salesforce platform. Of course, you could say that you don’t need because everything works smoothly. But don’t forget the one day where some issues will arise and troubles start to appear sooner than you ever can think. I this situation you will not want to miss the additional value as the following examples below.

  • Monitoring
    Give you a second eye to see what happened on the Salesforce side. With the additional monitoring layer, you have a real end-2-end monitoring and have 100% view on both sides of the connected platform.
  • Reprocessing
    Give you a possibility to independently do reprocessing of failed messages in case the middleware is not alive and can’t resend the data. This is to fix an emergency case where you have to make a quick fix inside Salesforce to reprocess the data which get failed due to some business data inconsistency.
  • Alerting
    Give you real business error alert which deals with error happened on your Salesforce side and not an error which happened on the middleware. The alert is sent from the Salesforce side and therefore is a real and authentic alert cover the business data error on your Salesforce platform.
  • Workflow
    Let you define a rule and pre-condition to process the message so that you can block wrong and dirty data from being mess up your business data on the Salesforce side. Complex business validation can run as a pre-condition before the data get posted and after the data get posted you can do a post-processing logic using the SKYVVA workflow.
  • Business logic
    When you need to add business logic to the data posting Salesforce give you great and flexible tool like apex, trigger, process builder and flow. Use one of them to add business logic to your pure data processing linked to the SKYVVA interface.
  • Batch and Scheduling
    When your data synchronization requirement comes to meet a mass volume data updates it is not correct and technically possible to use a real-time approach. In this case, you should move the processing of these mass data to a later free time window where you don’t break down the performance of the Salesforce Org. and thus impact the end-user while their business working hours. Instead, you should shift the processing to a suitable time for example in the night starting from 10:00 pm.

There are more additional value-added feature SKYVVA have added as integration services to the Salesforce platform. To keep this blog clear, short and comprehensible only these six value-added features will be explained in more detail.

Value-added #1 - Monitoring

To showcase the monitoring value-added feature we need to use a real interface example where the connected systems are SAP-ERP (sender), SAP-PI (middleware) and your Salesforce (receiver). The scenario is to change customer data in SAP and the changes will be synchronized immediately back to Salesforce. The diagram below shows the example flow.

SAP Salesforce Monitoring

In this screen, we can see the data changed in SAP for the customer 301557 and the old address in Salesforce. We expect to have the changed address from Salesforce to be updated on the Salesforce side.

Data change in SAP

Now have a look at the monitoring within the connected system as shown in the below picture. In this example, we are integrating to Salesforce using the standard API approach. In this screen, we can see the different monitoring on the sender e.g. SAP-ERP, on the middleware e.g. SAP-PI but on the Salesforce side there is no monitoring capability with the Standard Salesforce API. What you can do is going to check directly the sObject Account to see if the address data has been changed.  When you check the address on the account you don’t see the changes getting updated in Salesforce. So what happened and what can you do?

Monitoring SAP-ERP

What you can do in this case is to go to the debug trace and try to find the root cause why there the address has not been updated. Probably you will find something, probably not. As the Salesforce user or administrator, you cannot complain to the SAP-PI middleware team or the SAP-ERP team because all of them will prove you through their monitoring that the data was sent successfully where you can see it with the green flag. So what can you do to find the root cause in an easy way?

Unfortunately using the standard API approach with the middleware there is no monitoring capability inside Salesforce. The only way is to get your skilled apex developer team to try to find the root cause for this issue. Note that in this case we are using the asynchronous technique on SAP-ERP with Idoc and on SAP-PI the interface was designed as an asynchronous interface as well. There is no need to design this scenario using a synchronous interface because the SAP Idoc is an asynchronous technique. Therefore there will be no response of the API call telling the sender e.g. SAP-PI any error or exception. The message was sent successfully from SAP-PI to Salesforce and due to the nature of the asynchronous processing no further steps are needed on SAP-PI side.

So how to overcome this situation? Now let’s have a look at the same scenario which we rebuilt with SKYVVA. You are using, in this case, the SKYVVA connector on the SAP-PI/PO side. On the Salesforce side, you are using the SKYVVA service layer.

SAP-PI/PO middleware

When the message arrives from SAP-PI/PO middleware it goes to the SKYVVA message layer where it gets processed immediately. From the message flow, there is no different to the scenario where SKYVVA was not involved. The significant differences are that now you have the SKYVVA layer which can provide you the monitoring service. So how does it looks like?


As you can see in the screen we have also monitoring in Salesforce where you can immediately see the root cause what was happened. The error is clear and understandable for the Salesforce user and administrator. Now you find the error in minutes instead of hours without involving your apex developer team. This is a real End-2-End monitoring enhancing your middleware integration scenario.

Value-added #2 - Reprocessing

Let’s stay with the above example which we used to showcase the monitoring. Let have a look at the red message in the SKYVVA monitoring. Let’s assume that you as the Salesforce user or administrator understand the business error clearly and you need to get the address change because you have to send the quote to that customer today before the end of the business day. You cannot wait until the next day to risk to lose the deal. You take your phone and ring your SAP-ERP colleague to resend the incorrect message again. You reach him but unfortunately, he left the office already because it was short to the office closing hour. Your SAP-ERP colleague cannot resend it today and promise to send tomorrow earlier in the morning. But this will not help you because tomorrow morning is too late for your emergency situation now. So what can you do?

Since you have rebuilt the interface with SKYVVA just use the reprocessing feature. Open the message, change and save the data and do a reprocessing.

SKYVVA just use the reprocessing feature

Click on the button ‘Reprocess’ and confirm by clicking on the button ‘Yes’.

SKYVVA Reprocess

Now you can see a green message after the reprocessing.

message after the reprocessing

Now you can navigate from here directly to the business record to see the change made for the address update.

address update

The new address gets updated now after the reprocessing and you can use the new address to send the quote through your automatic quote process. Note that due to the simplicity the and clarity for the demonstration of the reprocessing feature we are not going to send the changes back to SAP. This is possible and makes sense but it would stretch the writing too long just for showing the reprocessing feature only. Also, note that the reprocessing you see here is the manual reprocessing. For this example, you have to do the manually reprocessing because the data is wrong and because you need to correct the data. But there is also others error where you don’t need to do a manual reprocessing but let the reprocessing job do it which you can schedule in an easy way. Have a look at the scheduling feature of the reprocessing job.

This is the message reprocessing job which you easily can start and stop by demand.

Value-added #3 - Alerting

The monitoring feature is great to see what happened on both sides. The annoying thing of the monitoring is that you always have to actively look to it. Wouldn’t it be great if you have some alert or notification when something gets failed and you get them as mail?

When looking to the scenario above SAP-ERP has an alerting, SAP PI PO has an alerting but on Salesforce there is no alert provided by the standard API. You would say that it is enough to have the alert on the middleware. Let’s have a detail look at the alert situation.

An alert should give you the real reason and root cause of an error which can happen in different places at any time. The error can be happened on SAP-ERP, on SAP PI PO, and on Salesforce and you need to have the original error text. In the above situation, the middleware alert the error happened on the middleware and not really what happened on Salesforce. It can reflect the error from Salesforce but there is a risk with this approach. The middleware has its own logic and code which can malfunction while transferring the message to Salesforce. In this case, it would alert its own error inside the middleware as for example “java.lang.StringIndexOutOfBoundsException: String index out of range: -1” which has nothing to do with the real error happened on Salesforce side.

What is the problem here? The alert is not authentic and it could be simply wrong because you get an alert which tells you the issue or error happened on the middleware but not happened on the Salesforce side. If the middleware stuck for some reason you could get alert which is delayed and was happened in Salesforce a few hours ago. This is crucial when you have a real-time scenario which also needs real-time alert from the source of truth. With the middleware in between, it is a kind of alert forwarding from Salesforce to you but not an alert delivering from Salesforce directly to you. From this example, you can see some drawback of the alerting capability.

  • Inaccurate alert and sometimes simply the wrong alert
  • Not real-time enough in case the middleware stuck or its performance gets degraded
  • Not direct but indirect through forwarding by the middleware

How can we overcome these issues? The only accurate approach to deliver alert on time, correct and with its original root cause is to have the alerting component directly in Salesforce as well. As you can see in the picture above each component e.g. SAP-ERP and SAP PI PO has its own alert component. There is a good reason to have a native alert component inside each platform. Now let’s see how we can have such a native alert component inside Salesforce.

SKYVVA has added with its service layer the native alert component to be able to deliver the true alert. Alerts are directly sent real-time from Salesforce to you without any delay. You will get the original error text and never see something like:

java.lang.StringIndexOutOfBoundsException: String index out of range: -1”.

Alerting can be defined in a granular way based on the integration or interface level. The integration is a logical group of interfaces. There are four different way to define alert delivery as below:

  • Using external mail
  • Using internal mail link to a user
  • Using task
  • Using chatter group

Here is an example, email alert.

You can click on the link and jump directly to the message detail and reprocess that failed message. With the option to use the chatter group you can use the social media feature to organize your alerting delivery. People following the group will get alert and there is no complex setup procedure to follow. There are also other alerting features for specific SKYVVA functionality like the Batch and CDC processing to observed the inbox of the basket or the change pointer table for data change.

Value-added #4 - Workflow

When you are using the Salesforce standard API to CRUD e.g. Create, Read, Update or Delete a sObject there is no validation or checks before create, update or delete a business record. It just above picture) which a service layer could bring to your integration need. It goes beyond the connectivity and provides you and your Salesforce team an easy way to develop, maintain and operate your daily integration need. This is what the SKYVVA service layer adds to the Salesforce Lightning platform which is missing for having the right and robust tool for doing the integration to and from Salesforce.executes it and modifies the sObject record immediately. But in most integration scenario you need to have some validation before modifying your business record otherwise you could mess up and create data inconsistency.

Have a look to the example which can be solved easily using the built-in SKYVVA workflow to have as a pre-condition check before an Asset gets modified. Here different condition consisting of the complex expression with formulas can be defined. A chain of ruled-based interface processing can be set up and provide you a powerful way to add complex message processing behavior than the simple CRUD operation. You can define any complex rule to validate first before you modify the sObject.

With the workflow, you cannot only define a rule or condition for interface processing. You can define a flow containing multiple steps involving in the message processing. Let’s assume you want to modify the account and the contact after each other. In this case, you can define a workflow which receives the account and contact data in a message and passing this message to the account and contact interface processing step. Thus you have defined a chain of processing step which can handle complex operation in one single API call.

You can define the different setting and run-time behavior for the workflow engine. For example, you can design a transaction-based processing flow and rollback all the operation within the flow when an error occurred. This guarantee transactional consistency.

Value-added #5 – Business logic

A message is transferred as the payload from the middleware to your Salesforce and through the Salesforce standard API, you can CRUD (Create, Read, Update, Delete) a sObject. The CRUD operation is the basic and elementary action you can think of handling with the business record in Salesforce. Sometimes it is enough just to CRUD sObject when your requirement is simple. Sometimes it is not enough when your integration scenario should handle some business requirement which goes over the CRUD operation.

With the SKYVVA workflow to define rules-based interface processing. Here you can use the built-in capability from Salesforce to add the business logic to the message processing. When your integration scenario goes beyond the CRUD operation then you need a powerful technique to add your business logic as you can do with a programing language. In this case, you can link an apex class to the interface and when the message arrives at the SKYVVA layer the processing will execute with your apex class logic where you can implement your business logic.

You can utilize the available programming and declarative tool for adding the business logic to your data integration. If you are a developer and can code in apex you can use apex trigger and apex class. If you are an admin and not an experienced developer you can use non-declarative tools such as the Process Builder and Flow. From the interface, you can link a Salesforce flow of type ‘Autolaunched’ and can build the business logic without any coding using the graphical flow.

Value-added #6 – Batch and Scheduling processing

Integration using middleware in between is mostly used to connect application to application scenario. This means that real-time scenario with end-user sitting and waiting on the other side is not common and thus not always a real-time and immediate data processing are needed. What sometimes need for mass and high-volume data integration between application system are batch and background processing to optimize the resource and performance and utilize the network, cpi and data storage.

Based on the integration scenario some use case makes perfect sense to use the real-time processing pattern. For example (1st scenario) when a user on the Salesforce side want to see the availability of a product in SAP-ERP then it makes sense to invoke an API and wait for the response. Such request is short running operation and will not hit the Salesforce time-out limit. When you want to update price by a nightly operation (2nd scenario) then it makes no sense to use a real-time processing pattern to update millions of prices. This would be technically not possible because of the Salesforce timeout limit and secondly make no sense because no user sits and wait to see the updated price immediately. It is enough to have the price update in the next day when the webshop will be open.


In fact, it is not a question whether the real-time (tight coupling) or batch/background driven (loose coupling) approach is better than the other. Both patterns fit perfectly when the given scenario is suitable. Do it real-time or batch based on your business requirement. The problem with the standard API is that it is not possible to delay the processing of the API or push it to run in the background job at a later time as for example in the night at 10:00 pm every day. The mechanism to do that is simply missing with the Salesforce standard.

SKYVVA service layer adds a scheduler and job processing component to the Salesforce platform which provides the batch and scheduling processing.

You can define the schedule in a different way to meet your business requirement. You can run every for example 15 minutes. You can run once at a certain time e.g. at 1:00 am or you can run every hour between for example 10:00 pm and 4:00 am.

You can select the days in the week and the month you want to exclude. This is a flexible way to define when message processing should start based on your requirement. You are not forced to process everything immediately if it would make more sense to process the data like a mass price update at the night time. Thus you can adjust and distribute the processing load and utilize your Salesforce resources and CPU time in a better way.

Different schedules are available for any kind of task you needed. For example with the batch processing and reprocessing scheduler you can push packages of message e.g. 10k per package and schedule the processing into the night time from 10:00 pm to 6:00 am for every hour. This utilizes the resources and distribute the load and keep the performance for of your Salesforce instance for the end-user while their working hours smoothly.

Starting and stoping schedule is easy by just clicking on the icon . Setting the schedule only need to click on the icon . All available schedule for the different task is generated automatically.


All six described value-added features will raise your integration quality to the next higher level giving you the operational instruments to ease and simplify the daily task. This method goes beyond the simple API integration approach where only pure connectivity is possible. When you want an enterprise-class integration then the only middleware approach is definitely not enough.

End-2-End monitoring and alerting increase the quality and improve error handling and daily operation tremendously. Message reprocessing give you a handy tool to handle emergency cases where the sender system is currently out of order. With workflow and business logic the simplicity and limitation of the CRUD operation can be overcome and complex business scenario can be easily implemented without much coding on the wrong side. Lastly, batch and scheduling feature enables to decouple the sender from the receiver and thus create less dependency which leads to optimized performance in the message processing for mass volume data.

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Daten Migration SMA Solar Technology AG

SMA Solar Technology AG

Sonnige Aussichten für Vertrieb und Service mit der Datenmigration von SKYVVA

Der Spezialist für Photovoltaik-Wechselrichter SMA Solar Technology AG hat die Salesforce Cloud für den weltweiten Vertrieb und Service eingeführt. Um einen fehlerfreien Datenaustausch und eine fehlerfreie Datenmigration zu gewährleisten, investierte SMA in die Integrationslösung SKYVVA.

Wenn die SMA Solar Technology AG über die Energieversorgung der Zukunft spricht, geht es unweigerlich auch um die digitale Vernetzung. Jetzt hat der Spezia-list für Photovoltaik-Wechselrichter seinem weltweiten Vertrieb und Service ein intelligentes Kundenmanagement-System (CRM) verpasst und führte die Sales-force-Cloud ein.

Für die tiefe Integration sowie den reibungslosen und fehlerfreien Datenaustausch zwischen Salesforce und SAP ERP baut SMA auf die Integrationslö-sung SKYVVA Integration Cloud des Beratungsunternehmens Apsara Consulting.

Mit Energie-Lösungen für Solaranlagen am Netz oder in netzfernen Regionen treibt die SMA Solar Technology AG aus Niestetal bei Kassel die Energiewende voran. Das breite Produkt- und Lösungsportfolio für solare Hausdachanlagen, gewerbliche Solar-stromanlagen und große Solarkraftwerke ermöglicht weltweit eine besonders effiziente Nutzung von Solarenergie. Produkt- und Service-Qualität werden seit der Unterneh-mensgründung 1981 großgeschrieben.

Wenn der Wechselrichter in einer Anlage doch mal eine Störung meldet, müssen Fach-handwerker oder EPCs (Engineering, Procurement and Construction, deutsch: Detailplanung und Kontrolle, Beschaffungswesen, Ausführung der Bau- und Montagearbeiten) mit aktuellen Service-Meldungen versorgt werden, damit das Problem schnell be-hoben werden kann.

Dank einer App sehen sie auf ihrem Mobilgerät, um welche Anlage es sich handelt, ob noch Garantien für die Geräte bestehen, es ähnliche Störungen schon früher gegeben hat und welche Ersatzteile für die Reparatur nötig sind.

Zusätzlich versorgen SMA Service-Techniker die Installateure vor Ort mit wichtigen Details zu den eingesetzten SMA Wechselrichtern. Möglich macht das die neue
Salesforce-Cloud – seit zwei Jahren bei SMA im Einsatz. Für Hans-Jürgen Borchert, Head of CRM Applications in der Corporate IT bei SMA, ist das ein Segen, denn „die Plattform Salesforce führt Vertrieb und Service weltweit zusammen.“

Die SMA Gruppe ist mit einem Umsatz von rund 900 Millionen Euro im Jahr 2017 ein global führender Spezialist für Photovoltaik-Wechselrichter, einer zentralen Komponente jeder Solarstromanlage. Das Produktportfolio umfasst Hausdachanlagen, gewerbliche Solarstromanlagen und große Solarkraftwerke. Intelligente Energiemanagement-Lösungen, digitale Energielösungen sowie umfangreiche Servicedienstleistungen bis hin zur operativen Betriebsführung von Solarkraftwerken runden das Angebot von SMA ab.

Die Herausforderung:
Für die weltweite Energiewende wird Solarenergie immer wichtiger. Um seine Kunden rund um den Globus zu betreuen, setzte SMA lange Zeit auf die Weiterentwicklung seines bestehenden Vertriebs- und Kundenmanagementsystems SAP CRM. Der Aufwand für die jeweiligen Anpassungen von Prozessen stieg jedoch mit zunehmender Internationalisierung. Ebenso die Kosten für Updates: Bei IT-Problemen vor Ort mussten Experten aus Deutschland eingreifen.

Standard-Lösungen wie Salesforce-Cloud haben viele Funktionen out of the Box (z. B. Customer-Portale oder Sprachvarianten). Das ist günstiger als Eigenentwicklungen. Außerdem haben Salesforce und deren Partner Spezialisten, die bei IT-Problemen weiterhelfen. Damit der Datenaustausch zwischen SAP ERP (Enterprise Resource Planning), die SMA im Einsatz hat, und der Salesforce-Cloud fehlerfrei klappt, ist eine hohe Integrationstiefe nötig. Für den reibungslosen und fehlerfreien Datenaustausch baut SMA auf die Integrationslösung SKYVVA Integration Cloud des Consultingunternehmen Apsara Consulting.


● Weltweit einsetzbare Lösung: Ein durchgängiges System statt bislang vieler Satellitenlösungen
● Bessere Kundenbetreuung, mehr Service und Angebote
● Erschließung von Marktpotenzialen
● Keine zusätzliche Middleware zwischen SAP und Salesforce-Cloud nötig
● Bessere Datenqualität dank fehlerrobustem Monitoring:
Fehler beim Datentransfer zwischen SAP und Salesforce können schnell entdeckt und behoben werden
● Support: Apsara ist für seine Kunden jederzeit ansprechbar, liefert regelmäßig Patches und Updates

Damit SMA alle Funktionen der Salesforce Cloud in vollem Umfang ausschöpfen kann, mussten zwei Welten miteinander verbunden werden: Die Salesforce Cloud und die Unternehmenssoftware SAP ERP. Wie in vielen Unternehmen ist SAP auch bei SMA das führende System, in dem Kundenstammdaten und betriebswirtschaftliche Daten zusammenlaufen.

„Um dieses Kernsystem ist seit 2015 die Salesforce-Welt entstanden“, so Hans-Jürgen Borchert. „Wir standen vor der Herausforderung, eine hohe Integrationstiefe zwischen beiden Systemen zu erreichen und gleichzeitig die Integrität und Konsistenz der Daten sicherzustellen.“ Wenn etwa die Buchhaltung in SAP Kundenstammdaten ändert oder neu anlegt, müssen dieselben Daten auch in der Salesforce-Cloud verfügbar sein – fehlerfrei versteht sich.

Apsara Consulting ist der Spezialist, der mit seiner SKYVVA Integration Cloud Lösung beide Welten miteinander verknüpft. Das Münchener Unternehmen bewegte sich lange Zeit in der SAP-Welt, bevor es zu einem „Salesforce Global Strategic Independent Software Vendor“ wurde. Es kennt sich daher bestens mit beiden Software-Systemen aus.

Für Apsara sprachen vor allem drei Gründe: SMA nutzt auch SAP Process Orchestration and Integration (SAP PO), damit der Daten- austausch zwischen SAP und Fremdsystemen wie Salesforce Cloud glatt läuft. 

„Mit SKYVVA brauchten wir keine weitere Middleware-Lösung“, sagt Hans-Jürgen Borchert. Zweitens fügt sich die native SKYVVA Lösung nahtlos in die Anwendungslandschaft von Salesforce ein – sie läuft vollständig auf der Lightning-Plattform (früher von Und drittens überzeugte das fehlerrobuste Monitoring der SKYVVA-Lösung.

Warum das so wichtig ist, wird schnell klar: Täglich bewegt SMA eine Unmenge an Daten. So müssen Produkt- und Gerätedaten ebenso wie Kundenkontakte aktualisiert, Angebote erfasst oder Rechnungen geschrieben werden. „Und obwohl wir einen massiven Datenaustausch haben, ist die technische Fehlerquote gering“, lobt der CRM-Verantwortliche die SKYVVA-Lösung für die Daten Migration.

Als besonderen Vorteil hebt er den hohen Automatisierungsgrad hervor: Kann ein Datentransfer aktuell beispielsweise aufgrund einer Sperre nicht durchgeführt werden, erkennt SKYVVA das und versucht es automatisch später noch mal. 

„Erst wenn es nach einer von uns festgelegten Anzahl an Versuchen nicht klappt, müssen wir eingreifen“, erklärt Hans-Jürgen Borchert. Das ist jedoch sehr selten. Sonnige Aussichten also für Vertrieb und Service.

Für uns ist das A und O, dass die Daten zwischen unserem führenden System SAP und der Salesforce-Cloud konsistent und korrekt ausgetauscht werden. Hier erweist sich die Integrationslösung SKYVVA von Apsara Consulting als eine sehr fehlerrobuste Lösung.

Hans-Jürgen Borchert

Head of CRM Applications bei SMA Solar Technology AG
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Salesforce SAP Integration Viessmann Group Success Stories

Viessmann Group

Ein umfassender Blick auf die Salesforce SAP Integration von dem Kunden Viessmann

Nach der Einführung von dem CRM-System Salesforce, setzte die Viessmann Gruppe in die Integrations Lösung SKYVVA, um eine einwandfreie Verbindung zum ERP System SAP und Saleforce herzustellen. Mittlerweile gehört Viessmann zu unseren langjährigen Kunden für die sich die SKYVVA Salesforce SAP Integration Lösung bewährt hat.

Industrie 4.0, Digitalisierung, Vernetzung – der Heizsysteme-Hersteller Viessmann in Allendorf an der Eder verspricht sich große Chancen von der Digitalisierung. Auf dem Weg dahin hat das Unternehmen jetzt einen großen Schritt gemacht: Es führte das Kundenmanagement-System (CRM) von Salesforce ein, das dem Vertriebsaußendienst einen zentralen Blick auf Privat- und Industriekunden gibt.
Damit sich Salesforce und SAP ERP einwandfrei verstehen, setzte Viessmann auf das Consultingunternehmen Apsara Consulting GmbH in München und seine bewährte SKYVVA Integration Cloud Lösung.

Michael Ringlebe ist durchweg zufrieden. Seit gut einem Jahr läuft das Kundenmanagementsystem (CRM) von Salesforce in Allendorf (Eder). Seitdem können die Vertriebsmitarbeiter in den Divisionen Heizsysteme und Industrieanlagen endlich das tun, was die Kernaufgabe des Außendienstes sein sollte: „Sie können sich nun noch effektiver um ihre Kunden kümmern,“ sagt er. Ringlebe ist Program Manager CRM bei der Viessmann IT Service GmbH, einem Tochterunternehmen des Heizsystem-Herstellers. Die 180 Experten betreuen die Informationstechnologie des Unternehmens und damit auch damit auch um das cloudbasierte CRM System Salesforce.

Seit einem Jahr verfügt der Außendienst über das mächtige Instrument für die Pflege seiner Kundenbeziehungen. Egal ob Absatz- und Umsatzzahlen, Konditionen, Treffen und Gespräche auf Messen, am Telefon oder den Mailverkehr – wo und was der jeweilige Außendienstler mit seinen Kunden besprochen oder vereinbart hat, läuft im CRM-System zusammen. „Damit hat jeder Vertriebler vom Erstkontakt bis zur jüngsten Bestellung die gesamte Kundenhistorie vor sich“, sagt Ringlebe. Gern spricht die Branche daher auch von der „360-Grad-Sicht“. Mehr noch: Mit Salesforce kann der Außendienst auch die Besuche der Kunden schneller und effektiver verwalten und potentielle Neukunden (sog. Leads) erfassen.

Das war nicht immer so. Die Viessmann Gruppe ist das, was gern als „hidden champion“ oder das Rückgrat der deutschen Wirtschaft genannt wird: Ein seit der Gründung im Jahr 1917 familiengeführtes Unternehmen, das 12.000 Menschen in 12 Ländern beschäftigt und für seine herausragenden Heizsysteme weithin bekannt ist. 

Viessmann erging es wie vielen Unternehmen. Die Produkte entwickelten sich schneller als manche Firmenprozesse. Darunter litt besonders der Vertriebsaußendienst, der mit einer Fülle an Software-Anwendungen arbeitete“, sagt Michael Ringlebe. So waren zum Beispiel Kundenvorgänge des Vertriebs und des Service für den jeweils anderen Bereich nicht ausreichend einsichtig. Daher klar, dass sich etwas ändern musste. Im September 2016 war es soweit, der Umbau begann. Mit Sales- force wollte Viessmann gleich zwei Probleme lösen: Alle Kundendaten in einem System konsolidieren und zugleich die Zahl der Lösungen deutlich vermindern.

Die Fakten zum Unternehmen:

Die Viessmann Gruppe ist ein international führender Hersteller von Heiz-, Industrie- und Kühlsystemen. Das 1917 gegründete Familienunternehmen beschäftigt 12.000 Menschen in 23 Produktionsgesellschaften in zwölf Ländern. In 74 Ländern hat die Gruppe Vertriebsgesellschaften und Vertretungen. Umsatz (2017): 2,25 Milliarden Euro, davon 54 Prozent im Ausland.

Herausforderung der Salesforce SAP Integration:

Insellösungen, Eigenentwicklungen und Software externer Anbieter – im Kontakt mit den Kunden verfügte der Vertriebsaußendienst der drei Viessmann- Divisionen über eine Vielzahl an IT-Instrumenten.  Was fehlte war ein durchgängiges Kundenmanagementsystem (CRM), das eine zentrale Sicht auf alle Vorgänge um einen Kunden erlaubte – ob Absatz- und Umsatzzahlen, Konditionen, Mailverkehr oder Gespräche auf Messen.


Viessmann suchte eine CRM-Lösung, die sich für künftige Anwendungen wie Marketing oder Service unkompliziert erweitern lässt. In der Salesforce-Cloud sah der Heizsystemhersteller die ideale Plattform. Die Anbindung an die bei Viessmann eingesetzte SAP ERP (Enterprise Resource Planning) erledigte das Consultingunternehmen Apsara Consulting mit seiner Integrationslösung SKYVVA Integration Cloud.

Nutzen einer Salesforce SAP Integration:

Wo immer die Vertriebsaußendienstler der Heizsysteme-Division oder die Außendienstler der Industrie-Division in den fünf deutschen Verkaufsregionen unterwegs sind – mit der Salesforce-Cloud haben sie Zugang auf alle Kundendaten.
Weniger Komplexität:
Ein durchgängiges System statt vieler, unverbundener Insellösungen
Bessere Datenqualität:
End-to-End-Monitoring garantiert, dass Fehler bei der Daten-erfassung schnell entdeckt und behoben werden können. Das vermeidet langwierige Fehlersuchen und spart bei täglich tausenden erfassten Datensätzen viel Zeit

Treten Fehler auf, z. B. eine falsche E-Mailadresse, erhalten die Anwender eine Mail, über den sie direkt den fehlerhaften Datensatz aufrufen und korrigieren können
Weil Salesforce eine Plattform ist, können weitere Elemente wie Marketing und Service bei Bedarf ans die CRM-Lösung angeschlossen werden Kundenvorgänge des Vertriebs und des Service für den jeweils anderen Bereich nicht ausreichend einsichtig.

Nun hat Viessmann für alle geschäftsrelevanten Bereiche SAP ERP (Enterprise Resource Planning) als zentrale Unternehmenslösung im Einsatz. Mit Hybris C4C bietet SAP auch eine eigene, Cloud-CRM-Lösung an. Was für den Wettbewerber Salesforce sprach, erklärt Ringlebe so: „Als Marktführer verfolgt Salesforce einen ganzheitlichen Lösungsansatz, was bedeutet, dass wir die Kundendaten auch als Basis für weitere Szenarien anderer Geschäftsbereiche wie Marketing und Service verwenden können.”

Grundsätzlich kann Salesforce auch als Stand-Alone-Lösung eingesetzt werden. Ihre Einführung vollzog Viessmann daher in zwei Etappen. „Wir haben zuerst eine Menge an Daten manuell ins System importiert, weil wir zunächst auch ohne die Synchronisation der Daten aus dem SAP leben konnten“, sagt Felix Leber, der bei Viessmann Globaler Salesforce Systemadministrator ist. So ging das Lead Management im September 2016 zuerst ohne eine Integration in SAP produktiv. Die Folge: Die Kundenstammdaten in SAP und Salesforce liefen auseinander – ein unhaltbarer Zustand für den Vertriebsaußendienst. „Für ihn war die Salesforce SAP Integration und damit die 360-Grad-Sicht auf Kunden unabdingbar“, sagt Michael Ringlebe.

Hier kommt Apsara Consulting und seine SKYVVA Integration Cloud Lösung ins Spiel. Das Consultingunternehmen aus München ist ursprünglich in der SAP- Welt groß geworden, bevor es zu einem „Salesforce Global Strategic Independent Software Vendor“ avancierte. „Wir wussten daher, dass sich die Münchener in beiden
Welten in aller Tiefe auskennen“, sagt Michael Ringlebe. 

Mit der SYVVA Integration Cloud Lösung für SAP hatte Apsara Consulting überdies eine Schlüsseltechnologie entwickelt, die entscheidende Anforderungen von Viessmann erfüllte: Reibungslose Salesforce SAP Integration und keine zusätzliche Software (Drittsysteme oder Middleware), sondern eine „direkte native End-to-End Integration von SAP PI und Salesforce“, sagt Ringlebe. Verständlich daher, dass sich Apsara Consulting gegen sechs Wettbewerber durchsetzte.

Zwischen SAP und Salesforce herrscht ein reger Datenaustausch. Täglich aktualisiert der Vertriebsaußendienst tausende Kundendaten – bei klarer Rollenverteilung: Über alle Hauptdaten eines Kundenaccounts regiert SAP als „Master“, das heißt der Außendienst kann sie in Salesforce einsehen, aber nur bedingt verändern. 

Zwölf solcher Inbound Interfaces, also von SAP nach Salesforce, ob Accounts, Angebote, Aufträge, Lieferungen oder Rechnungen hat Viessmann inzwischen produktiv gesetzt. In der umgekehrten Richtung (Outbound von Salesforce zu SAP) ist Salesforce bei den Kontaktdaten „der Master“. Um den problemlosen Datentransfer kümmern sich jedoch die Kollegen aus der IT, nicht etwa der Außendienst. Der soll verkaufen und die Kunden betreuen. „Dank des neuen CRM- Systems hat er dafür heute“, zeigt sich Michael Ringlebe überzeugt, „bedeutend mehr Zeit.“

Ein CRM-System in einer bestehenden Systemlandschaft von Grund an neu aufzusetzen, ist alles andere als trivial. Für uns hat es sich ausgezahlt, in Apsara Consulting einen Lösungsanbieter an der Seite zu haben, der sich in beiden Welten – SAP und Salesforce – hervorragend auskennt und die richtige Lösung für unsere Systemlandschaft bereitstellen kann.

Michael Ringlebe

Program Manager CRM - Viessmann IT Service GmbH
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn
Blog Why API is not enough

Why API alone is not enough for enterprise-class integration

What if I say, you don’t need to code a single line to perform enterprise-level Integration. Yes !! You heard right. Salesforce is all about low coding, but still, we as a developer are writing codes to perform different types of integration. Let remember my first blog where I come across the SKYVVA Data Loader and have worked with it as the replacement of the Salesforce Data Loader. SKYVVA provide not only the easy data loading and importing as we know with the data loader. SKYVVA provide more to do a complex and enterprise-class integration, which is hard to do with the API approach only. It is a very powerful tool which provides Integration with various advanced features and with no coding. This secret tool can change your organization’s Integration process completely.

The Salesforce standard API

So let’s first understand what are the standard ways to do Integration in Salesforce. I will shortly outline the different types of API’s which we can use for Integration and manipulating your Salesforce organization data. For the completeness of the API documentation and description please refer to Salesforce official help site. Let’s have a look on different API’s:


REST API is a simple and powerful web service based on RESTful principles. It exposes all sorts of Salesforce functionality via REST resources and HTTP methods. For example, you can create, read, update, and delete (CRUD) records, search or query your data, retrieve object metadata, and access information about limits in your Org. REST API supports both XML and JSON. Because REST API has a lightweight request and response framework and is easy to use, it’s great for writing mobile and web apps.


SOAP API is a robust and powerful web service based on the industry-standard protocol of the same name. It uses a Web Services Description Language (WSDL) file to rigorously define the parameters for accessing data through the API. SOAP API supports XML only. Most of the SOAP API functionality is also available through REST API. It just depends on which standard better meets your needs. Because SOAP API uses the WSDL file as a formal contract between the API and consumer, it’s great for writing server-to-server integrations.


Bulk API is a specialized RESTful API for loading and querying lots of data at once. By lots, we mean 50,000 records or more. Bulk API is asynchronous, meaning that you can submit a request and come back later for the results. This approach is the preferred one when dealing with large amounts of data. There are two versions of the Bulk API (1.0 and 2.0). Both versions handle large amounts of data, but we use Bulk API 2.0 in this module because it’s a bit easier to use. Bulk API is great for performing tasks that involve lots of records, such as loading data into your org for the first time.

Streaming API

Streaming API is a specialized API for setting up notifications that trigger when changes are made to your data. It uses a publish-subscribe, or pub/sub, model in which users can subscribe to channels that broadcast certain types of data changes. The pub/sub model reduces the number of API requests by eliminating the need for polling. Streaming API is great for writing apps that would otherwise need to frequently poll for changes.

API Limits

Total limits vary by org edition, license type, and expansion packs that you purchase. For example, an Enterprise Edition org gets 1,000 calls per Salesforce license and 200 calls per Salesforce Light App license. With the Unlimited Apps Pack, that same Enterprise Edition org gets an extra 4,000 calls. Total limits are also subject to minimums and maximums based on the org edition, but we won’t get into that here. If you want to know more, check out the API Request Limits link in the Resources section.

Which API to use in which case?

Choosing the right API for your integration needs is an important decision. Here’s some information on our most commonly used APIs, including supported protocols, data formats, communication paradigms, and use cases. Treat this section as a reference you can return to when you’re considering which API to use.

When to Use REST API

REST API provides a powerful, convenient, and simple REST-based web services interface for interacting with Salesforce. Its advantages include ease of integration and development, and it’s an excellent choice of technology for use with mobile applications and web projects. For certain projects, you may want to use REST API with other Salesforce REST APIs. To build UI for creating, reading, updating, and deleting records, including building UI for list views, actions, and dependent picklists use User Interface API. To build UI for Chatter, communities, or recommendations, use Chatter REST API. If you have many records to process, consider using Bulk API, which is based on REST principles and optimized for large sets of data.

When to Use SOAP API

SOAP API provides a powerful, convenient, and simple SOAP-based web services interface for interacting with Salesforce. You can use the SOAP API to create, retrieve, update, or delete records. You can also use SOAP API to perform searches and much more. Use SOAP API in any language that supports web services.

For example, you can use SOAP API to integrate Salesforce with your org’s ERP and finance systems. You can also deliver real-time sales and support information to company portals and populate critical business systems with customer information. Note that SOAP API has a well-defined standard by W3C consortium and reach a long maturity and thus old application systems still only support soap. Old applications which deliver value to your new digital scenario are still a great asset for your company and thus need to integration to the new digital process.

When to Use Bulk API

Bulk API is based on REST principles and is optimized for loading or deleting large sets of data. You can use it to query, queryAll, insert, update, upsert, or delete many records asynchronously by submitting batches. Salesforce processes batches in the background.

SOAP API, in contrast, is optimized for real-time client applications that update a few records at a time. You can use SOAP API for processing many records, but when the data sets contain hundreds of thousands of records, SOAP API is less practical. Bulk API is designed to make it simple to process data from a few thousand to millions of records.

The easiest way to use Bulk API is to enable it for processing records in Data Loader using CSV files. Using Data Loader avoids the need to write your own client application.

When to Use Streaming API

Use Streaming API to receive near-real-time streams of data that are based on changes in Salesforce records or custom payloads. For Salesforce record changes, Salesforce publishes notifications when the changes occur. For custom notifications, you can publish event messages. Subscribers can receive notifications using CometD – an implementation of the Bayeux protocol that simulates push technology. Clients can also subscribe to some types of events with Apex triggers or declaratively with Process Builder and Flow Builder. Use the type of streaming event that suits your needs.

Push Topic Event

Receive changes to Salesforce records based on a SOQL query that you define. The notifications include only the fields that you specify in the SOQL query.

Change Data Capture Event

Receive changes to Salesforce records with all changed fields. Change Data Capture supports more standard objects than Push Topic events and provides more features, such as header fields that contain information about the change.

Platform Event

Publish and receive custom payloads with a predefined schema. The data can be anything you define, including business data, such as order information. Specify the data to send by defining a platform event. Subscribe to a platform event channel to receive notifications.

Generic Event

Publish and receive arbitrary payloads without a defined schema.

Nature of API and its principal use case

As you have seen the different available API’s for integration and it’s use cases now let us look deeper into the nature and the principle behind the API. API become popular in the area of moving the application to a distributed network where business logic does not happen as the whole bunch of logic inside a monolith anymore. The decomposition and the distribution become the design principle of creating a new area of application which can be easily used over a distributed network such as the internet. To be able to communicate with now autonomy piece of software and application which can be specialized on a business domain the API becomes the vehicle to do that. The software application has to communicate with each other using API.

The application was decomposed to logical units which have to communicate with each other to fulfill the business task. Most of the time this communication is based on a synchronous way thus happen in real-time. This kind of communication is good to provide interaction between the application and the business user. On the other side, doing integration happened mostly in the background and run autonomously without having a user sitting and waiting for any response of an API. The work has to be done in the background and some time with a high volume of data automatically. With other words, the communication has to happen in an asynchronous way and need to support background and batch processing of high volume data.

The integration pattern

Looking to the available Salesforce standard API’s above except the bulk api you can see that they are operating in the synchronous pattern and thus follow the pattern of ‘tight coupling’ integration. When you are dealing with integration you will come across two principal approaches of doing the integration.

  • Tight Coupling
  • Loose Coupling

The following picture shows the two pattern:


A tightly coupled integration is one that creates a dependent relationship between Salesforce and whatever systems it’s being linked to by spreading the integration of business logic across those systems. While a tightly coupled integration could function just fine, it will inevitably cause scalability and maintenance problems in the long term. A loosely coupled integration, on the other hand, keeps the integration business logic separate from each system, thus create independence, interoperability, and decoupled application. This allows you to more easily modify your integration logic and to make changes to each individual system without fear of breaking any existing functionality.

Tight Coupling

With the Salesforce soap and rest API, you can greatly do simple so-called CRUD operation with the data which operate synchronously. This means that the caller application or client need to wait for the API to be finished. What happened with the client when the API run into an endless loop because of having a recursive trigger on sObject. Are the clients still responsive? Can the user use the application or is it going to be frozen? This kind of problems occurs when using tight coupling pattern with the wrong design. Tight coupling is a valid and great pattern to use and not saying that this pattern is useless. The things are that in integration world the use case is more and better fit to the so-called loose coupling of application inter-communication.

Due to the decomposed designed of having separate functional units in the modern software design such a tight coupling cause too many dependencies. It is such a big and monolith block which cannot easily be distributed over the internet. Lightway and functional encapsulated app is now the future and thus need to decouple the communication between that app. With this evolution in the last few decades, we could see new application vendors entering the market with new application software which provides a specific and well-suited business package. Therefore it is a strong demand to integrate them together in the right way with the right architecture.

Here some thought and fact to consider when you plan to use the synchronous and tight coupling architecture for your integration project.

  • Tight coupling model provides more interdependency on both the Integration systems.
  • It required more coordination between two systems while Integration as both are equally co-ordinating with each other during Integration data processing in order to success.
  • The caller needs to wait till API is finished which will result in blocking of the sender who is ending the requested data.
  • This waiting for API callouts results in bad user experience and bad performance for the client. Sometimes it appears to your users that your application is frozen. This will cause dislike and business damage if your user is not using your app anymore.
  • The client cannot use all its resources due because of waiting and idle time which results in frustration.
  • This API always follow Ping-Pong pattern to synchronize API between caller and provider hence more efforts to be taken when its tightly coupled Integration.

On the other side using tight coupling is also a valid way to do integration when your business cases need real-time interaction to support your business users. Only in this case, the disadvantages described above can be ignored.

Loose Coupling

As you see nowadays applications are breaking from its monolith structure of small, smart and maintenance able unit there is not tight coupling in the nature of application anymore. Thus the tight coupling pattern doesn’t fit much and application need to talks and interacts loosely together without having a user or process waiting for others. This kind of integration causes less inter-dependency and are thus great to maintain and change flexibility to meet any kind of new business requirements.

Loose coupling follows the principle of the asynchronous communication pattern. Imagine calling somebody by phone where you always need somebody to be available at the time you start the communication. With the asynchronous pattern, you don’t need your communication partner to be available and thus create less dependency on communication. This is for example when you write an email to a recipient. You are not blocked for hours you just sent your message and can turn around to do other things. This is one of the main advantages of not being blocked by the communication partner.

Lose coupling solve the disadvantages you have with the tight coupling pattern described above. It doesn’t need and bound huge resources on both side e.g. sender and receiver for doing the communication. It releases the client e.g. caller quicker and thus doesn’t create the impression to the user that the application freeze. Furthermore, if you integration scenario involved exchanging mass data e.g., for example, updating of millions of the product prices from an ERP system then there is no way to use the asynchronous communication to be able to send such amount of data using the bulk API.

There are a lot of great books and resources available over the internet which you can read to more precisely understand the communication pattern using for integration domain. In this blog, we cannot cover and explain all the theoretical aspect of the communication pattern because it would exploit the size of this blog. Let see in the following chapter how I found such a solution with SKYVVA which support both e.g. tight and loose coupling.

Integration using the API only approach

Now as we have seen and understood the two existing approach and pattern for doing integration let have a deeper look at how we can do the integration to manually program against the Salesforce standard API. Salesforce now provides both flavors of integration API which supports SOAP and REST. For a few years ago you can only use the SOAP API to do the integration and connect to your Org. Therefore older application still existing which uses the SOAP API. The picture below shows the view when doing integration using synchronous pattern with the Salesforce standard SOAP/REST API.

It shows the use case with an SAP cloud ERP application as a client which use API to synchronized data like Account, Contact, sales order, invoice, etc. In such a business case you have to deal with mass data to synchronize between SAP and Salesforce application system. It required autonomous data synchronization between that two application system without to have any users involved and it needs batch processing because of the mass of data.

The characteristic of using the Salesforce standard API is that it operates synchronously meaning that the client application has to wait until the operation which is triggered by the API is done. This can cause all the disadvantages we have seen above with the usage of the tight coupling approach. The most seen issue with using the standard API is that the client application seems to be frozen when there are too many requests at the same time.

Another aspect of using the Salesforce standard API is that it provides a very simple CRUD operation capability. But in real integration scenario, we need more than only create (C), read (R), update (U) and delete (D) the business record as for example a quote. We need more complex logic to do first before we are doing those basic REST operation. For example, before updating the quote we need to check based on the sales area assignment in SAP if this quote belongs to the correct territory area in Salesforce. So we need some business logic which needs to do beforehand.

The real integration scenario for an enterprise is much more than only doing the simple CRUD-operation. You need a full-fledged of services on the Salesforce side to be able to provide a stable integration not only in term of simple connectivity but also to support the daily operation when something is going wrong. Doing this you need an integration service layer sitting on the Lightning platform such as I could found with the SKYVVA solution.

Looking to the picture above you can see the filling gap (the black whole in the above picture) which a service layer could bring to your integration need. It goes beyond the connectivity and provides you and your Salesforce team an easy way to develop, maintain and operate your daily integration need. This is what the SKYVVA service layer adds to the Salesforce Lightning platform which is missing for having the right and robust tool for doing the integration to and from Salesforce.

Why integration needs both patterns?

As integration problems and use cases are too different we cannot say that the tight or loose coupling will be the only right solution for a requirement. If you need real-time to see, for example, the availability of a product on the stock then you simply need to solve this requirement using the tight coupling pattern and thus provide the real-time experience to your user who is waiting on his mobile device to see. If you need to synchronize the account address data which is enough to see them in the next day then you can use the loose coupling pattern to delay the batch processing of the account data update to a nightly job. Thus you don’t disturb the business user who is working on the main business hour during the day. 

One approach and architecture style is not enough in solving today integration need for Salesforce eco-system. If you are using a technology which supports only one of that communication pattern you will be lost in providing a stable, reliable and on-time connected digital business with your Salesforce platform. You simply need a tool which supports you in doing integration using both patterns in an effective way and without demanding from you to be an API developer expert. With SKYVVA I found such a toolset providing both patterns with the native Salesforce technology. No additional tools and middleware are needed to provide enterprise-class integration.

After having explained the Salesforce standard API, the two integration pattern and showing you the need of having both patterns to build any integration now lets us have a look to a few features offered by SKYVVA solution. Note that all the feature we will show you below is possible only because of the service layer from SKYVVA which in fact is the decoupling layer. Let me also repeat here again that SKYVVA supports both patterns and let you do a real-time integration scenario by by-passing the SKYVVA staging layer in the same manner you can do with the Salesforce standard API. The differences are that you get more functionality with the SKYVVA solution then when doing the integration manually yourself or let it done by a developer team who need deep knowledge and skill for API programming.

The SKYVVA added-value we want to showcase in the below chapter are the following:

  • Message Monitor, which give you a handy tool for monitoring incoming and outgoing messages
  • Message Reprocessing, which allow you to correct wrong incoming data a do reprocess without having to ask the sender application to send the data again.
  • Alerting, ease your life not to actively and permanently looking to the monitor to see what is going wrong. Instead, you will get an alert and notification easily to your mobile device or chatter group.

How to monitor in case something is going wrong?

Let us start with a question if your interface and integration you have developed always run smoothly without any issue? Do you have never had a failed data integration due to incorrect data e.g. wrong date and currency format or the user entered simply incorrect data at the sending application? How do you deal with all kind of errors you face at the daily operation. If you are a Salesforce experienced developer you probably have no problem to find out the root cause for integration error. But do you want to spend your resources every day for doing the integration error which can be easily done for example from your admin or end users colleagues? This is the point and time-saving issue I come across while using the SKYVVA solution which provides me all these benefits in a very simple way.

With SKYVVA you now have end-2-end monitoring because the messages are kept for monitoring purpose in the SKYVVA service layer and staging area. Without the SKYVVA service layer, you would have only the monitoring capability provided by the sender application and the middleware. This value-added feature is provided exclusively by the SKYVVA service layer.

The screen below shows an example of the monitoring screen where you have different options to find the messages. For example, the most used searching options are to find the message based on its content e.g. by entering the account name. With one mouse click, you have a clear view of your data and can compare easily on a business level without having to be a Salesforce developer expert to be able to read the debug log and traces.

It provides flexibility to monitor your Integration data by specific date and time as well. Hence you don’t need to be always present in front of your system to perform data Integration.

Depending on the processing different message status filter options are available like

Completed: When API call is successful and data is successfully posted the status is completed.

Failed: When data is posted successfully but due to some reason it is failed for example due to mismatch of data type like its text field in sender but it’s number field in Salesforce, in that case, it cannot post the record. With the monitoring screen, you can actually monitor the reason for the failure of data after the API call.

Pending: When your data is sent by the sender but pending to be posted in salesforce then message status change to pending.

Canceled: When data is canceled after API calls then message status changed to canceled

Please refer to the SKYVVA online tutorial and documentation page to see the detail of the monitoring capability here: 

Easy data fixing and correcting using the reprocessing feature

Imagine an example where you have to bring your sales quote and order from an ERP-System such as SAP to Salesforce for your sales representative to provide a clear picture of customer quote and order amount. Quote and order can be synchronized to Salesforce immediately with the SAP quote which has been changed in SAP. Such a process happened in the back-office by your colleagues who are using SAP to create and change the quote and order. Now imagine that being human people your colleague can make a mistake and enter the wrong data into the quote. Instead of entering the correct currency format he/she has entered a wrong one which is not recognized by Salesforce. The posting of the quote thus fail. 

What to do now? You can ask your colleague to correct the data on the SAP system and send it again. What happened when it is close to the business day and your colleagues left the office already? There is no one who can correct the wrong currency. The problem you have now is that it is close to the end of the business day and you have to send the correct quote from Salesforce to the potential client. Of course, you can shift to send the quote tomorrow. But if you are not the only vendor who sends the quote to that potential client and if your competitor can send by the end of the business day and not you what is going to happen? Imagine this scenario which can damage your business!

Such a scenario and use case happened in the reality and you need a possibility to independently do the correction and reprocessing of the application data posting e.g., in this case, to update the Salesforce quote with the correct currency from SAP. SKYVVA allow you to do such a data correction with the ability to reprocess the data immediately. Thus you can correct the wrong currency and post your quote successfully. Now you can send the quote before the end of the day to your potential client. You even can set up a scenario back to send the changed data using the process build process with the SKYVVA callout functionality to update the changes you made back to SAP. 

Start to use the message monitor to look for failed messages or jump from your email inbox where you got the alert and jump to the failed message. In the failed message make the necessary data correction and reprocess it.

Why alerting can help you

As you have seen having an additional component to monitor data in Salesforce is a great help for your daily operation to fix integration failure. If you don’t have the monitoring component your only way is to dig into the debug trace and look for possible failure. This is complex, time-consuming and needs experienced apex developer with deep API knowledge. With the monitoring, you can delegate this kind of work to your Salesforce admin and event business users. You are free to develop other nice application your company might need.

Monitoring allows you to actively look, search and see the integration data failure. What to do if you don’t have time to look every 30 minutes to the monitoring? You are mostly busy with meeting and some other task and cannot afford to open for every 30 minutes the monitoring page. This is why alerting comes into place. With the message failure alerting from the SKYVVA solution, you don’t need more to actively care about any data integration failure. Even while you are drinking a cup of coffee you will know when something is going wrong with your data integration. SKYVVA provide you real-time alert and notification to your email inbox, create a task for your user and use the social media functionality using the chatter group to post alert.

With this feature, the SKYVVA solution has added the missing part to the Salesforce platform regarding alerting functionality. Now you have alongside the integration chain alerting capability. It is alerting everywhere and nothing can be get lost anymore. This is possible due to the decoupling and integration service layer of the SKYVVA solution added to the Salesforce Lightning platform.


Finally, you reach the end of this long blog. There are some more functionality and added value which I come across the SKYVVA integration solution while I have been working with this great native app. For example, regarding the reprocessing feature, you don’t need to do every data reprocessing manually. There are schedulers available in the SKYVVA solution which will do the reprocessing automatically. For data failure like business data record lock due to concurrent processing on the same record by an end user and the integration user at the same time the reprocessing job will resolve it. There is no need to do the reprocessing manually. The scheduler can be flexibly defined e.g. to run for example every 15 minutes or only on Sunday at 10  pm in the evening.

As you have seen it is not the matter or question of if you can do integration or not with the existing Salesforce standard API. The answer is YES you can do everything yourself if you have the right skill and coding experiences. But are you really providing the integration with the same quality and robustness which enterprise-class integration needed if you only use the API connectivity approach? What about supporting decoupling processing between the client and Salesforce? Can this be done using the standard Salesforce API?

What about the error handling including alerting functionality you need for a real robust integration? Do you have all of the required functionality to handle your daily data synchronization operation which includes the monitoring, reprocessing and alerting? If you just need a ping-pong and simple CRUD operation connectivity you can use the Salesforce standard API but if you want to have more or if your business needs a stable and maintenance-able integration and data synchronization then there is no way not to go for a professional solution like a middleware. But what to do when your company doesn’t have the budget to use a full-blown middleware because of cost reason? If you are in such a situation but need an enterprise-class integration solution like a middleware can provide it then definitely my recommendation is to have a look to the SKYVVA app.

Find here the latest release version and make the first try with the free SKYVVA Data Loader. For a test version with all the functionality but limited to 30 days of validation fill in the contact formula and ask for a trial key.

Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn

Release Spring ´19 SKYVVA Agent – Official Version 1.49

SKYVVA Agent - Official Version 1.49

Spring ´19 Release

Mit dem Spring ´19 Release sind folgende Erweiterungen mit der neuen SKYVVA Integration Agent Version 1.49 verfügbar:

  • Button ‘New Property’ for create new properties file is Agent
  • File name with Merge file.
  • Property File Cannot Duplicated
  • Web Service call through Agent
  • Initial mode not work with auto-switch mode
  • Retrieve more than 50K records from Salesforce with Agent Outbound Processing
  • New properties name “Replace Header” in adapter type File with file type CSV
  • Update the Next Run Date after the schedule setting is change in the Agent UI
  • Scheduler based condition
  • Read file extension with ignore case
  • XML IChained with Hierarchical difference way

Bug Fixed

  • MySQL Server: Time zone value unrecognized
  • Package Size on interface when we filled in Agent UI doesn’t update on SF
  • Agent cannot process attachment while attachment don’t have in folder
  • Hard Deleted doesn’t work with database
  • Login wrong Server Environment
  • Scheduler is working when it Stopped
Share on facebook
Share on Facebook
Share on twitter
Share on Twitter
Share on linkedin
Share on LinkedIn