I have a set of ZBAPI structures on a server of a company in which we developed and installed a custom application.
I am having to use a lot of the same BAPIs in the same application for a different company.
Is there any quick way in which I can move the Structure, Function Module, Business Object and the BAPI code itself from one SAP system to another?
Yes. Use the built-in Change and Transport System (CTS), preferably by creating a Transport of Copies (ToC). You may also want to check this question.
Related
Is there a SAP standard function module that transfers data of new items from ERP to CRM system?
It depends of what kind of items you wanna replicate:
For business-partners there are standard functions which are adjustable from SPRO
For vendor data you can utilize FSSC_BP_REPLICATION or CRM_VENMAP_TO_CRMM_BUT_VENDNO reports
Order replication is triggered automatically and you do not have to do anything, just to ensure the BAdI CHANGE_BEFORE_UPDATE is active
Check also the most common problems that are faced during distribution and their solutions: TIPS to check the distribution of documents between CRM and ECC
Manual ERP->CRM tables replication is not recommended by SAP, however there are also special tools for this. For example, SAP Data Services and SLT:
https://www.guru99.com/sap-ds-sap-data-services-in-sap-hana.html
https://blogs.sap.com/2018/10/30/slt-configuration-for-data-replication-from-s4hana-fashion-to-sap-car-system/
https://blogs.sap.com/2015/05/15/transformation-capabilities-of-sap-slt-vs-data-services/
I may be completely off-track, but is it possible to use BO universe as a Source to my SSIS/SSRS.
We've been given a task recently where we've to tap into BO to make SSRS reports. Can we do that?
And if need be can we use that as a source to SSIS for any further transformation.
Also - please help in providing link on how to do it. Google provided me only links where SQL is a source instead of destination.
Thank you for your help.
You can, if:
you can query the universe using the REST interface (i.e. web service)
you can consume the OData flow that is returned as the result set
For more information, have a look at SAP BusinessObjects BI Universe Connector Technical Guide.
There are some requirements regarding the version of BusinessObjects and the type of universe you're using:
SAP BusinessObjects BI 4.1 SP2 or later are supported
the universe has to be created with the Information Design Tool (i.e. have a .UNX extension)
The current limitations are described in the aforementioned article.
You cannot use Business Objects Universes as a data source in SSIS/SSRS. Universes do not contain data, they are simply an abstraction layer that generates SQL for reporting.
You also cannot link SSRS/SSIS to Business Objects to use universes to generate SQL for downstream use. The links simply do not exist.
I am creating a software for retail shops and I want that my software support SQL Server and SQLite. If the user is a standalone (one PC) select the sqlite database and if it is over the network then choose the SQL Server option.
I am developing this software in Visual Studio 2010 and vb.net language.
As research we have three types of connections in Visual Studio, ODBC, OleDB and MSSQL.
And OLEDB can support MS-Access database and SQL Server.
Any comment and idea is highly appreciated.
The best way to code your applications is to abstract functionality into different tiers or layers. This can mean lots of things and can get quite complex, but the general idea is to keep your application's parts separated. Let's assume you have an inventory form in your program where you can look up current inventory. The form that displays the inventory doesn't need to know what database your customer is running. Generally you're better served by it not knowing. Likewise, your code that accesses the respective database, whether it be SQL Server, SQLite, or Access, doesn't really need to know what your Inventory form is going to do with the data it is retrieving. All your Inventory code should be doing is displaying your inventory in a way that's most useful to your customer, and all your data coding should be doing is getting the data that is requested of it.
The route I would probably take in your situation is to create a data provider class. Inside that class is where you would encapsulate logic for the different database functions you may have, as well as the different database systems your customers may have. Say for instance a store owner just received a shipment of products and needs to add one to his store's inventory. Ideally, your program should simply be able to perform a call like DataProvider.AddInventory(). Inside the DataProvider class, you would write code to keep track of which database solution the customer is using as well as an implementation of logic for each of the database solutions you'd like to support. Ideally, you should implement every data function you may need your application to perform so that it can be called very simply like the AddInventory() example.
Implementations of data providers can be as simple or complex as you like. In some cases where you're going to have multiple applications written in multiple different languages on multiple different platforms accessing your data source from multiple locations, it may make sense to write some sort of middleware. In your case, it sounds like this is the type of application that will reside "in house" and should be served fine by abstracting the data access to a separate class.
I have to implement bridge application that deals with SAP and write some function modules. I'll have serious SAP consultant that will guide me through data structure I need but how can I practice with ABAP at the moment? I'm so confused with variety of SAP products so I have several questions:
What shall I download and install to practice with ABAP
Are functional modules similar to Stored Procedures in RDBMS?
Is ABAP the only language to write SAP function modules?
May I install some trial SAP modules (SAP FI for instance), where can I find them?
Thank you in advance!
There is a SAP Netweaver Developer Edition available on the sap developer network. Netweaver is basically a java based web stack in front of the SAP ERP System. Depending on the SAP installation, you may not have Netweaver. If you have, you can either use java to create a web based component in Netweaver or use ABAP to create a RFC capable function module which you can then call either through one of the RFC connectors (java/.net) or by exposing it as a web service (transactions "sicf" and "soamanager" as a starting point).
Function modules are much more like web services, not stored procedures. Some of them expose structures of the data dictionary, some (mostly the recommended modules called BAPI) expose business objects.
SAP Modules like SAP_APPL (basically the ERP stack) or HR are available for SAP customers (you can create as many test and training systems as you want, as long as the users are the same as on the production systems), as a developer you will probably only get access to basic functionality.
In this moment, I have two web applications(one application is an MVC2 application for the management of my project and the second is an application with web services). Both applications have to deal with the database and have Nhibernate for querying the database. Is this a good pattern?, if not what can i do?
Edit 1
Both applications can write to the database. I have a dll project that handle the database transactions and have de nhibernate instance named "Repositorio". Nevertheless, each application will have a different instance of Repositorio.dll so there is going to be multiple threats to the database, what do i have to do to make both application use the same instance of Repositorio.dll?
The answer depends on whether or not both applications can write to the database.
If one is read-only, I'd say you're safe.
I not, I'd argue that a service-oriented approach would recommend creating a service that provided an interface for both applications and was the sole owner of the database.
"service-oriented" does not mean that the service has to be a distributed component (e.g., SOAP or REST or RPC). If you encapsulate the database access in a component with a well-defined interface you can choose to share the component as a DLL in both applications. Only make it a distributed component if that makes sense for both applications.
That sounds perfectly fine to me even if both applications write to the database. I would simply recommend you create a third project as a class library with all your nHibernate related stuff to avoid writing any redundant code in both projects.