I have to send the goods movement via IDoc from 2 different SAP systems to S/4 HANA via SAP Process Orchestration (PO).
I need to recognize in S/4 HANA from which system the IDoc is coming, do some mapping based on the sender, and after the mapping, I have to book the goods movement.
My solution is to extend the standard IDoc type MBGMCR03 with 1 segment with 1 field (SOURCE_SYSTEM).
How can I fill that field before creating/sending the outbound IDoc?
On the receiving system ( in this case S/4 HANA), where can I do the mapping before using the standard inbound functionality?
The customer does not want to do any mapping in Process Integration (PI).
There is already sender system exists as SNDPRT on EDI_DC40 segment.
<EDI_DC40 SEGMENT="1">
<TABNAM>EDI_DC40</TABNAM>
<MANDT>100</MANDT>
<DOCNUM>405820</DOCNUM>
<DIRECT>2</DIRECT>
<IDOCTYP>IDOC_TYPE</IDOCTYP>
<CIMTYP />
<MESTYP>MESSAGE_TYPE</MESTYP>
<SNDPOR>SAPXXX</SNDPOR>
<SNDPRT>XXXCLNT200</SNDPRT>
<SNDPFC>LS</SNDPFC>
<SNDPRN></SNDPRN>
<RCVPOR>ED_STATU</RCVPOR>
<RCVPRT>LS</RCVPRT>
<RCVPRN>LS</RCVPRN>
<CREDAT>20131010</CREDAT>
<CRETIM>162137</CRETIM>
<SERIAL>20131010162137</SERIAL>
</EDI_DC40>
Related
I troubleshooting an issue downstream of the GDS and I wanted to confirm if Amadas has an <namePrefix> XML object for customer reservation.
When that data is being ingested into its destination, this is what I would like to be seeing:
<IndividualName>
<namePrefix>Mr</namePrefix>
<nameFirst>FIRST</nameFirst>
<nameSur>SUR</nameSur>
But I'm seeing
<IndividualName>
<nameFirst>JOHN MR</nameFirst>
<nameSur>DOE</nameSur>
</IndividualName>
If they do, then I'll engage with the party between the GDS and our PMS to resolve the issue but I need to be sure if this XML object exists.
Regards
At this stage, I've traced the missing XML Object back to the stage before the GDS.
If the XML object is not present as an XML object, I'll engage the destination vendor to work on a solution.
Our Current Flow
GDS - Does <nameprefix> exist?
Parent Hotel Company - NamePrefix does not exist when it flows downstream.
Site Minder - Is only a passthrough. Nothing is changed
Destination (Opera Cloud) - NamePrefix XML Does not exist when ingested
We are using the Gemfire WAN topology and have problems setting up the gateway-senders.
Couple of assumptions:
- Replicated regions
- Serial gateway-senders
- manual-start is false for all gateway-senders
Let's say we have 2 clusters, within each cluster, we have 2 members (Member A and Member B)
Member A's cache.xml
<gfe:gateway-sender id="gateway-sender-A" parallel="false" remote-distributed-system-id="2" manual-start="false" />
<gfe:replicated-region name="data" scope="DISTRIBUTED_NO_ACK">
<gfe:replicated-region name="subData" data-policy="REPLICATE" scope="DISTRIBUTED_ACK">
<gfe:gateway-sender-ref bean="gateway-sender-A"/>
</gfe:replicated-region>
</gfe:replicated-region>
Member B's cache.xml
<gfe:gateway-sender id="gateway-sender-B" parallel="false" remote-distributed-system-id="2" manual-start="false" />
<gfe:replicated-region name="data" scope="DISTRIBUTED_NO_ACK">
<gfe:replicated-region name="subData" data-policy="REPLICATE" scope="DISTRIBUTED_ACK">
<gfe:gateway-sender-ref bean="gateway-sender-B"/>
</gfe:replicated-region>
</gfe:replicated-region>
There is a problem when we run start up the two members within one cluster. It raises this error:
java.lang.IllegalStateException: Cannot create Region /data with [gateway-sender-A] gateway sender ids because another cache has the same region defined with [gateway-sender-B] gateway sender ids
Looking at the "High Availability for Gateway Senders" documentation, our understanding is that we can create 2 gateway-senders, in which only one will be doing the sending at a given point in time. Ultimately, we want to have 2 gateway senders (one in each member) for one cache region, one as the primary sender and the other as the secondary sender.
Thanks
From Geode documentation, it says
For serial Senders, Queue HA is achieved by configuring identical serial Senders in multiple members. The Queue is replicated between the members.
So if the two gateway senders in member A and B is doing the same job (except their primary/secondary roles), you should use "identical" setting.
Among gateway senders, there will be one that manages to acquire a specific distributed lock and becomes the primary sender, usually the first one comes up. I don't see a property to force one to become primary.
Geode is the open source version of Gemfire if you wonder.
After changing the sender-ids to the same for both members, we have another problem:
java.lang.IllegalStateException: Cannot create Gateway Sender
"some-gateway-sender-id" with manual start "false" because another
cache has the same Gateway Sender defined with manual start "true
It seems like our problem was the inconsistent format.
Member A used XML format
<?xml version="1.0"?>
<!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 8.0//EN" "http://www.gemstone.com/dtd/cache8_0.dtd">
Member B used Spring Gemfire Data format
xmlns:gfe="http://www.springframework.org/schema/gemfire" xsi:schemaLocation="http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd">
<gfe:gateway-sender ...>
We switched to using the Spring Gemfire Data format for both members, and it solved both issues.
TL;DR, the gateway-senders need to have the same ids if they are in the same cluster and use consistent cache xml formats.
I have a huge list of transport requests, I want to get a report of all included objects of these (as a "sum-up"). I couldn't find a report in transaction SE03, SE09, SE10, nor in Transport Organizer Tools.
Help is appreciated.
I found out, use SE11, goto table E071, filter by TRKORR (multiple selection is possible), group result in Grid Display by PGMID, OBJECT and OBJ_NAME.
I don't know if there's a standard report for that but these are the tables in SAP where you can get that information to make a Z report:
E070: Change & Transport System: Header of Requests/Tasks
E07T: Change & Transport System: Short Texts for Requests/Tasks
E071: Change & Transport System: Object Entries of Requests/Tasks <--- Here are the objects to be transported.
E070A: Change & Transport System: Attributes of a Request
E070C: CTS: Source/Target Client of Requests/Tasks
In the case of table 'E070' there's a relationship with itself between fields 'TRKORR' (Request/Task) and 'STRKORR' (Higher-Level Request).
Hope it helps.
here i have got one issue.can some one please help me to resolve this.
i was trying to extract some data to DS 0FI_AP_6...
then in InfoPackage Monitor I can see like..
-->Requests (messages): Everything OK
-->Extraction (messages): Everything OK
-->Transfer (IDocs and TRFC): Missing messages or warnings
-->Info IDoc 2 : sent, not arrived ; IDoc ready for dispatch (ALE service)
Data Package 1 : 23752 Records arrived in BW
Data Package 2 : 15216 Records arrived in BW
Request IDoc : Application document posted
Info IDoc 1 : Application document posted
Info IDoc 3 : Application document posted
Info IDoc 4 : Application document posted
-->Processing (data packet): Everything OK
Data Package 1 ( 38672 Records ) : Everything OK
in Status Menu I am having message like...
Missing data packages for PSA Table
Diagnosis
Data packets are missing from PSA Table . BI processing does not
return any errors. The data transport from the source system to BI was
probably incorrect.
Procedure
Check the tRFC overview in the source system.
You access this log using the wizard or following the menu path
"Environment -> Transact. RFC -> Source System".
Error handling:
If the tRFC is incorrect, resolve the errors listed there.
Check that the source system is connected properly to BI. In
particular, check the remote user authorizations in BI.
Please suggest me how to resolve this issue...
thanks in advance for your help and quick reply is much appreciated.
But what the worst thing is I deleted the infopackage in PSA by mistake.
In the normal case, if I repeat the process again, the delta load would be OK, but now the delta load remains error.
so gurus,
1. how can I restart my delta loading correctly?
2. I want to modify the timestamp in the delta table, but how to do it ?
Go to T-Code RSA7 in the source system. This will tell you the date/timestamp that the delta is set to. If the date was changed to a range that no longer works then you will need to re-initialize the datasource in the BW system side. However, the Delta date may still be fine becauase it may have never been changed when you tried to first do your load because of the connection issues.
You can create a new infopackage and set the update to Initialize Datasource with Data Transfer. This will essentially run a full load from the datasource and then reset the delta pointer date/timestamp to when you ran it. This way you will capture all the data that you needed and anything that was already in the PSA should be overwritten.
Also note that you should delete or set the request status to red on the previous request that may contain bad data in the PSA.
From the original error it seems like you are having an RFC connection issue between the datasource and BW. Contact your BASIS support and have them check the connection to make sure it is good. To ensure that your datasource is extracting properly you can run t-code RSA3 on it in the source system. This will ensure that the extraction of data is working properly.
How to check for the delivery report of the sent message. I am using PHP and I have the SMPP account. Can somebody help me with the checking of delivery report?
Will I get a delivery report as message like we get in our mobile?
Or the status of the send function will do for it?
Using SMPP you can retrieve delivery report in the following ways.
First choice is to set registered_delivery parameter to 1 when you send submit_sm PDU.
In this case SMSC should send you deliver_sm PDU with esm_class = 0x04 containing delivery report.
Other way is to request delivery status with query_sm command but this may generate more traffic if polling SMSC too often.
If you're asking about the format in which the Delivery_Receipt will be delivered back to the source then it's carried as the user data payload in the SMPP deliver_sm or data_sm operation.
The following fields are relevant in the deliver_sm and data_sm operations when used for transmitting delivery receipts:
• source address (i.e. source_addr_ton, source_addr_npi, source_addr)
• destination address (i.e. dest_addr_ton, dest_addr_npi, destination_addr)
• esm_class
• message_state
• network_error_code
• receipted_message_id
SMS delivery receipts are regular SMS text messages generated by SMSC, but esm_class = 0x04 is used to differentiate them. The esm_class = 0x04 means PDU direction is SMSC > ESME and short message contains SMSC delivery receipt short message.
Short message area of deliver_sm SMPP PDU consists below text format which is encoded using dcs=0x00 data coding scheme (i.e. SMSC Default Alphabet according to the SMPP specification):
id:{message_id}
sub:{message_sub}
dlvrd:{message_dlvrd}
submit date:{message_submit_date} done
date:{message_done_date}
stat:{message_stat}
err:{message_err}
Sample delivery receipt message text:
id:40072910491427628 sub:001 dlvrd:001 submit date:1007291049 done date:1007291049 stat:DELIVRD err:000
Adding the following link here for details of processing the sample message above:
SMS Delivery Reports with SMPP protocol