VAN-XI-SAP Scenario for EDI
Hi,
We would like to get the EDI from our trading partner's VAN to our XI using Seeburger EDIINT AS2 adapter. Is this possible? If yes, what are the things we should keep in mind.
Your help will greatly appreciated.
Thanks.
Karma
Hi,
Check out this document
http://www.seeburger.com/fileadmin/com/pdf/SAP_Exchange_Infrastructure_Integratio_Strategy.pdf
Also this thread
Need Material on Seeburger Adapters.
Thanks,
Prakash
Similar Messages
-
Mapping handling in third party vs SAP PI for EDI 850
Hi Experts,
Can I know Pros and Cons for hanling mapping translations in third party vs handling mapping translations in SAP PI for EDI 850 interface.
We are already paying money to third party. I just need pros and cons.. we will choose best approch based on your valuable points
Appreciate your help.
Regards,
Krishna.Hi Mohan,
Pros:
SAP PI is a middleware and all Middlewares work pretty much on the same principles.
I am assuming that EDI 850 would have some sort of structure, [ to be honest I have not worked on EDI but just read about it] and SAP PI would require you to convert this structure into XML -> the only language SAP PI understands.
Now, I am sure there are lots of third party adapters available in the market for EDI. PI will give you flexibility to convert this interface into any kind of requirement be it JDBC/FILE/IDOC or anything and vice versa is also true. PI give you this enormous ability to convert to and from any format as long as it is viable.
Last but not the least, it will provide a robust system with Alerting and Monitoring.
Cons: You may have to invest on a third party adapter to read the EDI
You can read the following links for more abt EDI and SAP PI:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/10b17369-9522-2c10-84a6-d75d8a8ace22?overridelayout=t…
Step by step interface for IDOC ORDERS05 to EDI 850 using B2B add-on and getting Functional acknowledgement 997 back
EDI 850 to R/3 scenario
Thanks & Regards,
Tejas Bisen -
Hi experts,
We would like to use SAP PI for creating EDI Documents, Could you let me know what are the options available other than using Seeburger.We would be mostly using this for sending invoices to external edi systems.I would appreciate your help.Many thanks.Hi,
>>>Could you let me know what are the options available other than using Seeburger
you can send XML files to your EDI provider if the provider supports it
or even IDOC-XML (there are also providers that support this)
so it all depends on the EDI provider you use
Regards,
Michal Krawczyk -
hi can anybody tell me how the concept of EDI works?
1)do configurations like setting logical system, partner profiles etc have to be made?
2)is there standard idocs like MATMAS or CREMAS that are sent via EDI?
3)is there a step-by-step procedure for EDIhi anjali,
IDocs are basically a small number of records in ASCII format, building a logical
entity. It makes sense to see an IDoc as a plain and simple ASCII text file, even if it
might be transported via other means.
Any IDoc consists of two sections:
the control record
which is always the first line of the file and provides the administrative information.
the data record which contains the application dependent data, as in our example below the material master data.
We will discuss the exchange of the material master IDoc MATMAS in the
paragraphs that follow..
The definition of the IDoc structure MATMAS01 is deposited in the data dictionary
and can be viewed with WE30.
The very first record of an IDoc package is always a control record. The structure of this control record is the DDic structure EDIDC and describes the contents of the data contained in the package.
The control record carries all the administrative information of the IDoc, such as its origin, its destination and a categorical description of the contents and context of the attached IDoc data. This is very much like the envelope or cover sheet that
would accompany any paper document sent via postal mail.
For R/3 inbound processing, the control record is used by the standard IDoc
processing mechanism to determine the method for processing the IDoc. This
method is usually a function module but may be a business object as well. The
processing method can be fully customised.
Once the IDoc data is handed over to a processing function module, you will no
longer need the control record information. The function modules are aware of the
individual structure of the IDoc type and the meaning of the data. In other words:
for every context and syntax of an IDoc, you would write an individual function module or business object (note: a business object is also a function module in R/3) to deal with.
The control record has a fixed pre-defined structure, which is defined in the data
dictionary as EDIDC and can be viewed with SE11 in the R/3 data dictionary. The
header of our example will tell us, that the IDoc has been received from a sender
with the name PROCLNT100 and sent to the system with the name DEVCLNT100 .
It further tells us that the IDoc is to be interpreted according to the IDoc definition called MATMAS01 .
All records in the IDocs, which come after the control record are the IDoc data. They are all structured alike, with a segment information part and a data part which is 1000 characters in length, filling the rest of the line.
All records of an IDoc are structured the same way, regardless of their actual
content. They are records with a fixed length segment info part to the left, which is
followed by the segment data, which is always 1000 characters long.
You can view the definition of any IDoc data structure directly within R/3 with transaction WE30.
Regardless of the used IDoc type, all IDocs are stored in the same database tables
EDID4 for release 4.x and EDID3 for release 2.x and 3.x. Both release formats are
slightly different with respect to the lengths of some fields.
Depending on the R/3 release, the IDoc data records are formatted either according
the DDic structure EDID3 or EDID3. The difference between the two structures
reflects mainly the changes in the R/3 repository, which allow longer names starting
from release 4.x.
All IDoc data record have a segment info part and 1000 characters for data IDoc type definition can be edited with WE30 Data and segment info are stored in EDID4 .
All IDoc data records are exchanged in a fixed format, regardless of the segment type. The
segments true structure is stored in R/3s repository as a DDic structure of the same name.
The segment info tells the IDoc processor how the current segment data is structured
and should be interpreted. The information, which is usually the only interest, is the name of the segment EDID4-SEGNAM.
The segment name corresponds to a data dictionary structure with the same name,
which has been created automatically when defining the IDoc segment definition
with transaction WE31 .
For most applications, the remaining information in the segment info can be ignored
as being redundant. Some older, non-SAP-compliant partners may require it. E.g.
the IDoc segment info will also store the unique segment number for systems, which
require numeric segment identification.
To have the segment made up for processing in an ABAP, it is usually wise to move
the segment data into a structure, which matches the segment definition.
When R/3 processes an IDoc via the standard inbound or outbound mechanism, the IDoc is stored in the tables. The control record goes to table EDIDC and the data goes to table EDID4.
All IDoc, whether sent or received are stored in the table EDID4. The corresponding
control file header goes into EDIDC.
There are standard programs that read and write the data to and from the IDoc base.
These programs and transaction are heavily dependent on the customising, where
rules are defined which tell how the IDocs are to be processed.
Of course, as IDocs are nothing more than structured ASCII data, you could always
process them directly with an ABAP. This is certainly the quick and dirty solution,
bypassing all the internal checks and processing mechanisms. We will not reinvent
the wheel here.
To do this customising setting, check with transaction WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development.
All inbound and outbound Documents are stored in EDID4 Avoid reinventing the
wheel Customising is done from the central menu WEDI and see the points,
dealing with ports, partner profiles, and all under IDoc development
The declaration of valid combinations is done to allow validation, if the system can
handle a certain combination.
The combination of message type and IDoc type determine the processing algorithm. This is
usually a function module with a well defined interface or a SAP business object and is set up
in table EDIFCT.
The entry made here points to a function module which will be called when the IDoc
is to be processed.
The entries for message code and message function are usually left blank. They can
be used to derive sub types of messages together with the partner profile used.
Figure 25: Assign a handler function to a message/message type
The definition for inbound and outbound IDocs is analogous. Of course, the function
module will be different.
R/3 uses the method of logical process codes to detach the IDoc processing and the
processing function module. They assign a logical name to the function instead of specifying the physical function name.
The IDoc functions are often used for a series of message type/IDoc type
combination. It is necessary to replace the processing function by a different one.
E.g. when you make a copy of a standard function to avoid modifying the standard.
The combination message type/IDoc will determine the logical processing code,
which itself points to a function. If the function changes, only the definition of the processing codes will be changed and the new function will be immediately
effective for all IDocs associated with the process code.
For inbound processing codes you have to specify the method to use for the
determination of the inbound function.
This is the option you would usually choose. It allows processing via the ALE
scenarios.
After defining the processing code you have to assign it to one or several logical
message types. This declaration is used to validate, if a message can be handled by
the receiving system.
The inbound processing code is assigned analogously. The processing code is a pointer to a function module which can handle the inbound request for the specified IDoc and message type.
The definition of the processing code is identifying the handler routine and assigning a serious of processing options.
You need to click "Processing with ALE", if your function can be used via the ALE
engine. This is the option you would usually choose. It allows processing via the
ALE scenarios.
Associate a function module with a process code
For inbound processing you need to indicate whether the function will be capable of
dialog processing. This is meant for those functions which process the inbound data
via call transaction. Those functions can be replayed in visible batch input mode to
check why the processing might have failed.
There are several common expressions and methods that you need to know, when dealing
with IDoc.
The message type defines the semantic context of an IDoc. The message type tells
the processing routines, how the message has to be interpreted.
The same IDoc data can be sent with different message types. E.g. The same IDoc
structure which is used for a purchase order can also be used for transmitting a sales order. Imagine the situation that you receive a sales order from your clients and in addition you receive copies of sales orders sent by an subsidiary of your company.
An IDoc type defines the syntax of the IDoc data. It tells which segments are found
in an Idoc and what fields the segments are made of.
The processing code is a logical name that determines the processing routine. This
points usually to a function module, but the processing routine can also be a
workflow or an event.
The use of a logical processing code makes it easy to modify the processing routine
for a series of partner profiles at once.
Every sender-receiver relationship needs a profile defined. This one determines
the processing code
the processing times and conditions
and in the case of outbound IDocs
the media port used to send the IDoc and
the triggers used to send the IDoc
The IDoc partners are classified in logical groups. Up to release 4.5 there were the
following standard partner types defined: LS, KU, LI.
The logical system is meant to be a different computer and was primarily introduced
for use with the ALE functionality. You would use a partner type of LS, when
linking with a different computer system, e.g. a legacy or subsystem.
The partner type customer is used in classical EDI transmission to designate a
partner, that requires a service from your company or is in the role of a debtor with
respect to your company, e.g. the payer, sold-to-party, ship-to-party.
The partner type supplier is used in classical EDI transmission to designate a
partner, that delivers a service to your company. This is typically the supplier in a
purchase order. In SD orders you also find LI type partners, e.g. the shipping agent.
Message Type How to Know What the Data Means
Data exchanged by an IDoc via EDI is known as message. Messages of the same kind belong to the same message type.
The message type defines the semantic context of an IDoc. The message type tells
the receiverhow the message has to be interpreted.
The term message is commonly used in communication, be it EDI or
telecommunication. Any stream of data sent to a receiver with well-defined
information in itis known as a message. EDIFACT, ANSI/X.12, XML and others
use message the same way.
Unfortunately, the term message is used in many contexts other than EDI as well.
Even R/3 uses the word message for the internal communication between
applications. While this is totally OK from the abstract point of view of data
modelling, it may sometimes cause confusion if it is unclear whether we are
referring to IDoc messages or internal messages.
The specification of the message type along with the sent IDoc package is especially
important when the physical IDoc type (the data structure of the IDoc file) is used
for different purposes.
A classical ambiguity arises in communication with customs via EDI. They usually
set up a universal file format for an arbitrary kind of declaration, e.g. Intrastat,
Extrastat, Export declarations, monthly reports etc. Depending on the message type,
only applicable fields are filled with valid data. The message type tells the receiver which fields are of interest at all.
Partner Profiles How to Know the Format of the Partner
Different partners may speak different languages. While the information remains the same, different receivers may require completely different file formats and communication protocols.
This information is stored in a partner profile.
In a partner profile you will specify the names of the partners which are allowed to
exchange IDocs to your system. For each partner you have to list the message types
that the partner may send.
For any such message type, the profile tells the IDoc type, which the partner expects
for that kind of message.
For outbound processing, the partner profile also sets the media to transport the data to its receiver, e.g.
an operating system file
automated FTP
XML or EDIFACT transmission via a broker/converter
internet
direct remote function call
The means of transport depends on the receiving partner, the IDoc type and message
type (context).
Therefore, you may choose to send the same data as a file to your vendor and via
FTP to your remote plant.
Also you may decide to exchange purchase data with a vendor via FTP but send
payment notes to the same vendor in a file.
For inbound processing, the partner profile customizsng will also determine a
processing code, which can handle the received data.
IDoc Type The Structure of the IDoc File
The IDoc type is the name of the data structure used to describe the file format of a specific IDoc.
An IDoc is a segmented data file. It has typically several segments. The segments
are usually structured into fields; however, different segments use different fields.
The Idoc type is defined with transaction WE30, the respective segments are defined
with transaction WE31.
Processing Codes
The processing code is a pointer to an algorithm to process an IDoc. It is used to allow more flexibility in assigning the processing function to an IDoc message.
The processing code is a logical name for the algorithm used to process the IDoc.
The processing code points itself to a method or function, which is capable of
processing the IDoc data.
A processing code can point to an SAP predefined or a self-written business object
or function module as long as they comply with certain interface standards.
The processing codes allow you to easily change the processing algorithm. Because
the process code can be used for more than one partner profile, the algorithm can be
easily changed for every concerned IDoc.
The IDoc engine will call a function module or a business object which is expected
to perform the application processing for the received IDoc data. The function
module must provide exactly the interface parameters which are needed to call it
from the IDoc engine.
In addition to the writing of the processing function modules, IDoc development requires the
definition of the segment structures and a series of customising settings to control the flow of the IDoc engine.
In Summary
Customise basic installation parameters
Define segment structures
Define message types, processing codes
Segments define the structure of the records in an IDoc. They are defined with transaction WE31.
Check first, whether the client you are working with already has a logical system
name assigned.
The logical system name is stored in table T000 as T000-LOGSYS. This is the table
of installed clients.
If there is no name defined, you need to create a logical system name . This means
simply adding a line to table TBDLS. You can edit the table directly or access the
table from transaction SALE.
The recommended naming convention is
sysid + "CLNT" + client
If your system is DEV and client is 100, then the logical system name should be:
DEVCLNT100.
System PRO with client 123 would be PROCLNT123 etc.
The logical system also needs to be defined as a target within the R/3 network.
Those definitions are done with transaction SM59 and are usually part of the work
of the R/3 basis team
see this link for all info on idocs
http://abapprogramming.blogspot.com/2007/11/abap-idocs-basic-tools.html
thanks
karthik
reward me points if usefull -
Hi All,
I have to send EDI 857 Information from SAP. Could you please let me know which IDOC should i use to achieve the functionality. I appreciate if anybody can send me the mapping document of EDI 857 from SAP.
Thank You,
SureshHi,
I have to send the Shipment/Billing Information and the triggering point is When we save the Shipment of the Delivery.. I am using SHPMNT03 IDOC for Shipment Details.. I am thinking of extending the SHPMNT03 IDOC for getting the billing details. Is this the right way for sending the Shipment/Billing Information to EDI 857 ?
Thank You,
Suresh -
Problem with Sender Agreement for EDI File to Idoc scenario
I'm configuring PI for EDI with Seeburger Adapter (Calling as a Module) and I'm having an issue with the Sender Agreement using File Adapter.
Process used is File to IDOC. EDI data will be picked up from VAN (Using existing FTP process rather than using Seeburger FTP) and stored in a folder which is being accessed by PI to send to R/3 to create orders.
All my inbound EDI will be stored in same folder which should be picked up by XI and distribute the same depending upon the respective scenario's in ID and respective mapping/config in IR.
The whole process IR & ID works fine and also creates Idoc in R/3, if I configure for one customer for EDI 850, but when I try to configure for second customer for same EDI 850 having same ANSIX12 version (V4010) as previous customer, I get stuck at the Sender Agreement part for this second customer because I use the same CC for File read for both the customers (Scenarios) and since there is a limitation with File Adapter "sender channel must not be assigned to more than one sender agreement ".
How can I create the Sender Agreement using the same CC for my other scenario?
I tried creating multiple CC for different scenario but when I place a test file for customer A, I see that its being picked up by both CC's.
Pl Advise.
Thanks!
PSRYou need to configure splitter as module in sender file adapter (classifier->bic->splitter) as well as define a message splitter(with partner number and Seeburger mapping) in Seeburger workbench.
Thank you for the reply Aamir,
Do you have any document which can guide me through the process?
Does Seeburger Workbench play any role here? because I'm not using See FTP adapter to connect to my VAN. We get the data from the VAN using FTP process but not using See FTP. I'm using BIC to generate an XSD and SDA file, rest everything is in XI using File to idoc and IDOC to file process.
Thx
PSR -
ALE/IDOC and RFC/BAPI Integration Scenarios with SAP DS for ESA v3
Hi,
we are planning two PoCs of Integration Plattforms. One of our major requirement set is SAP Integration into our existing SOA.
Because we also have R/3 4.7 Systems in production, we are planning to test ALE/IDOC and RFC/BAPI Integration scenarios with these Integration Plattforms.
My question is:
We are looking for are smart solution to get a SAP Test Environment, where we can test ALE/IDOC und RFC/BAPI Integration scenarios.
It is possible to do this with SAP DS for ESA v3 or shall we better use IDES for that purpose?
Best regards,
StevenHi Abhishek,
This is our scenario. We are doing an integration of SAP HR r/3 system with the CRM system. We need housing information details of the employees which we have in custom infotype 9310 in SAP HR system and we need those details in the CRM system. So am planning out for an ALE/IDOC approach for the integration and gonna maintain the 9310 details in a custom table. In the CRM system, we gonna build a BOL layer for accessing the 9310 details. Also i'm preparing a HLD for this process. I wanna read and go through few same HLD's before i submit my proposal to my client. Please suggest me and help me out.
Thanks in advance.
Regards,
Arunmozhi. -
Scenario for interface between a non sap system and a SAP erp
Hello,
I need some help in order to elaborate a interface between a SAP ERP and a non-sap system with the help of a XI system.
- At first regarding the interface from the non sap system and a SAP ERP :
the non sap system sends a flat file to the XI system. The flat file contains a row with header data and rows with item data. We were thinking when the file arrives to the XI system, to save the data in a header database and in a items database in XI. is it possible ?
And then to have like a job that reads the database and creates idoc and sends them to the SAP erp and updates the xi header and items database with a flag that means that the records have been sent to the SAP erp.
- Regarding the interface SAP erp to non SAP system:
the SAP erp sends idoc to XI. Then the idocs are transformed into flat file.
Is this scenario possible ?
Do we need any adaptator between the non sap system and the XI ?
Thank you for your help
ChristopheHi Bontron,
Idoc doesnot support synchronous call. So you can use either proxy or function module and inturn call the idoc from them and send response back to xi. You need to have two scenarios for your design.
Scenario1: Source File (file adapter) -- xi -- Dump into database tables (Jdbc Adapter)
Scenrio2: Pickup form Database tables (Jdbc Adapter) -- xi -- RFC Adapter ---> This is synchronous call.
Regarding the interface SAP erp to non SAP system
You can send idoc to xi and from there use File adapter to send to the receiving system.
These blogs may help you to some extent:
/people/sap.user72/blog/2005/06/01/file-to-jdbc-adapter-using-sap-xi-30
https://wiki.sdn.sap.com/wiki/display/XI/step%2bby%2bstep%2bRFC%2bto%2bJDBC%2bscenario (your scenario will be opposite to this)
Regards,
---Satish -
1)what is the best way to follow the scenario for Out look integration with share point using SAP Gateway?
2)workflow concepts for Purchase order?
3)Email triggering from out look for an approval process of PO? how these scenario can be best implemented with updated functions in Duet Enterprise.Hi,
I do not have much idea on gateway integration with outlook but found out this document GWPAM Workflow Template which can be helpful for you to start with.
also you may want to post your question in SAP Microsoft Interoperability forum
Regards,
Chandra -
Best practise for EDI-IDOC scenario
I want to create a EDI-IDOC scenario for invoicing our customers.
There are 2 options that I can use, create partner profiles of type KU for each of our customer that we will be invoicing or have
a LS for XI and configure the same.
My company has around 400 customers. So incase i chose to go with KU then i have to configure 400 partner profiles right?
Which is the best practice for this scenario?As stated above, you can use LS partner instead of KU partner. There are, however, some pros and cons to be considered:
1) Post-processing agent assignment. If you have different people working with different customers you can assign them as post-processing agents to the respective partner profiles. If you switch to LS you will need to have only one agent (it might be a group of people though).
2) When you have a separate profile for each customer then the customer number is included in the IDoc control record. This allows to quickly view the IDocs by customer number. E.g. if a customer calls and asks where the heck is my document then customer service could easily see all the IDocs for that customer in WE05, for example, and check what's going on. With LS they would have to dig into the segments for that.
So the business process requirement decides this. If you don't care for any of this you might be even better off using LS instead of KU, because it requires less maintenance. -
can any body pls give the real time scenarios for the ale/ido/edi. pls very urgent. ur answer will very helpful 2 me.
Hi,
Please check these examples of real time scenarios are:
1. Outputting Purchase Orders as IDOCs on saving the PO.
2. Outputting Inbound Delivery on receipt of ASNs.
3. Processing Goods Receipt from a third party system.
Regards,
Ferry Lianto -
SAP IDES Scenarios for IS-OIL & Supply Chain Managment
Hello,
Will anyone share the link / where can i get SAP IDES business Scenarios for SAP IS-OIL & Supply Chain Management (SCM)
PVHello All,
I am looking for link SAP IDES Solutions for Model Company for SAP IS-OIL & SCM modules,
Similar to: please go through the below link
SAP Library - IDES - The SAP Model Company
with all scenarios with transactions clearly
https://help.sap.com/saphelp_46c/helpdata/en/a9/fc4f35dfe82578e10000009b38f839/content.htm
PV -
IDES Bus Scenarios for SAP IS-OIL solutions
Will anyone provide url for Business scenarios for SAP IS-OIL SD and MM modules
Here is the link go through it,
http://help.sap.com/bp_bblibrary/600/HTML/X14_EN_AU.htm
Regards,
Rao -
Hi all,
I have some questions about SAP XI and EDI.
We are planning to get the SAP XI to handle EDI message e.g. ANSI 850, but it looks like XI does not handle EDI out of the box. From what I read we still need to buy an EDI adaptor to handle the EDI-to-IDOC and IDOC-to-EDI processing. e.g. Seeburger adaptor.
Actually I don't quite get this, isn't it XI contains a set of tools that allows us to do the mapping? Can we just use those tools to create EDI map without buying the seeburger adaptor? If we cannot create EDI map ourselves, then isn't it SAP XI is just an expensive message router??
Any inputs are greatly appreciated. Thanks.XI has its own built-in message mapping tool (drag and drop GUI), upon which you can do "any-to-any" mapping. You can also do your mapping in ABAP, Java, or XSLT environments if you feel that the message (graphical) mapping tool doesnt enable you to do everything you want.
So yes ... you can use XI's mapping functionality to map from iDoc to EDI format. However, this can be quite a complex exercise: you will need to setup the structure of the (target) EDI message/data type, and then carry out the mapping yourself - depending on the type of interface, this could be quite a complex exercise (typically EDI structures contain a very large number of fields).
Once the iDoc has been mapped into the EDI format ... you will need to transmit (send) the EDI message to your (business) partner system, who is typically outside of your firewall (B2B). This means you need to communicate with them using a secure communication protocol (typically OFTP via VAN in EDI scenarios). And this is where the SeeBurger EDI adapters add value. They enable you to connect to VANs (Value Added Networks) using OFTP (or x.400), and also provide mappings for some EDI scenarios (which you can use).
iWay also provide adapters for this purpose. -
How to use pre-defined scenarios for RosettaNet with XI 3.0
Hi all.
I am working in Comgroup Shanghai co. ltd. which is partner of SAP China.
We have a potential customer who use RosettaNet as their Supply Chain EDI system.
I would like to make a demo for demostrate the pre-defined scenarios for RosettaNet RNIF 2.0 packages.
Where can I find such guideline ? I have checked the article: implementing RosettaNet with XI 3.0, but it cannot help me.
Another question is how I can develop my own scenarios for the RNIF standards which are not included in XI RosettaNet business package ?Hi Andy,
See the instructions below after you installed the RosettaNet STK.
Below given is the sample config for PIP3B2 Scenario. Part I is using STK and Part II is using 2 XI systems.
<b>Part I. Test Using STK</b>
In your XI ID:
1) Define both the parties 1) Shipper(Your Partner) 2) Receiver(Your company) with identifiers like DUNS Number.
2) In ID goto>Tools>Transfer Integration Scenarios from IR-->select the scenario "PIP3B2_Receiver" from the drop down list.
3) Follow the 4 steps in the config wizard.
4) While creating your CC, create it from the channel template delivered with the RosettaNet BP.
4.1) Specify the URL for STK which should be in the following format
http://<STK Server>:<port>/rosettanet/servlet/listenerServlet?userId=<Party Name>
4.2)In the location fields, enter your location and your partner location.
In your STK
1) Start the RosettaNet STK.
2) enter the UserID<Partner Name in XI>
3) Select the Test Scenario, 3B2V01.01-AdvanceShipmentNotification-0001-Scenario-Shipper
4) Enter Global Business ID(DUNS Number) and Location ID for both the partners. These fields should be same as in your R/3 Party configuration.
5) Enter the URL as follows:
http://<XI Server:<J2EE_Port>/MessagingSystem/receive/RNIFAdapter/RNIF
If everything is configured correctly as mentioned, you should be able to test your single-action scenario.
<b>Part II Test using another XI System</b>
For these follow the steps above for XI Config.
Configure one XI System as PIP3B2 Shipper using the Scenario "PIP3B2_Shipper" and config wizard as mentioned above.
Configure the other XI as PIP3B2 Receiver using the scenario "PIP3B2_Receiver" and config wizard.
In the Url field, specify the URL as follows:
http://<XI host>:<J2EE_Port>/MessagingSystem/receive/RNIFAdapter/RNIF
Hope this helps.
Regards,
Sam Raju
Maybe you are looking for
-
How do I add a hover feature on my pictures
I would like to add a hover feature to my pictures so when I hover over the picture it turns to white and adds words. I found this feature in the Roxy website: http://www.roxy.com & See attached picture. Can someone help how to set this feature up?
-
not sure of my opions. any ideas
-
90 % of the YouTube videos don't play on my new iPad air
-
Getting Adobe Extensions and 3rd Party Plug-ins into PSCC 2014; how do I do it?
How do I get my Adobe Extensions and my 3rd party plug-ins into PSCC 2014?
-
Creation of similar fixed assets
Hello I am using a bapi bapi_fixedasset_create1to create similar assets, but its only creating a similar asset even though i am passing '8', it should create 8 assets. Please suggest if i need to use some different BAPI or the importing parameter of