Thursday, September 29, 2011

Handle the custom EDI Document Version Number

Many EDI customers customizes the Standard EDI document version numbers  for e.g for 850 EDI document Standard Version of  X12 protocol are 5010, 4010 etc but customer wants to have his own version numbers e.g 5010VICS , 4010UCS in the outbound EDI file.
Thus to accomplish it you need to customize the document version from 4010 to the desired 4010UCS in the 850 communication capability of the trading partner.

But  you can get the below error-
AIP-50547: Trading partner agreement not found for the given input values: From party[NAME] "Glbalchips", To party[NAME] "ACME", Business action name "null"; also verify agreement effectiveToDate
at oracle.tip.adapter.b2b.tpa.RepoDataAccessor.getAgreementNameByBaTPName(RepoDataAccessor.java:2345)
at oracle.tip.adapter.b2b.tpa.TPAIdentifier.identifyTPA(TPAIdentifier.java:186)
at oracle.tip.adapter.b2b.tpa.TPAProcessor.processTPA(TPAProcessor.java:589)
at oracle.tip.adapter.b2b.tpa.TPAProcessor.processIncomingTPA(TPAProcessor.java:240)
at oracle.tip.adapter.b2b.engine.Engine.processIncomingMessage(Engine.java:1832)
at oracle.tip.adapter.b2b.engine.Engine.incomingContinueProcess(Engine.java:2573)
at oracle.tip.adapter.b2b.engine.Engine.handleMessageEvent(Engine.java:2443)
at oracle.tip.adapter.b2b.engine.Engine.processEvents(Engine.java:2398) 



Cause:
Business Action can be null when the Document Type or the Document Type Revision is not configured correctly.
For any transaction, inbound or outbound, B2B finds the following parameters in order to determine an agreement.
a. From Party
b. To Party
c. Document Type
d. Document Type Revision.
Oracle B2B extracts the Document Type and Document Revision from the transaction set of incoming EDI Document . i.e UNH Segment.
If there is a mismatch in the Document Type or the Document Revision in the B2B configuration (different from the EDI Incoming File), then B2B cannot determine the Business Action.
If any one of the above values are configured incorrectly or not configured , B2B throws "AIP-50547: Trading partner agreement not found for the given input values".

Solution:
Check if Document Type has some custom name. (B2B does not allow to customize the document type name.)
If Yes
Rename the document type to just 850 ( or any standard type) as follows:
In the present configuration,
Login to B2B ---->Partners --->Protocols ---->EDI X12 over Generic Exchange ----
->Document Protocol Revision --->Details
In the Document Type section , rename 850UCS to 850
Re-create the agreement and re-deploy the configuration. 

Happy learning.

Regards
Ayush



Thursday, September 22, 2011

Delimiters other than UTF-8 in B2B

We all know that by default B2B only supports UTF-8 encoding style but some times there is a need to send the dellimters for eg. Segment Delimiter or Element Delimiter in the outbound EDI file which are not in encoding style of UTF-8 set. If such delimiters are used then B2B gives following error
Error in B2B The Interchange Trailer is missing. The segment itself may be missing or the Segment Delimiter may be missing.

The above issue typically erupts due to UTF-8 encoding.
The error can be removed by placing the below property in tip.properties file located in B2B server config folder
"oracle.tip.adapter.b2b.encoding=ISO-8859-1"
Please make sure that you bounce the Server after saving the change.

A small point but a very important one.


Cheers
Ayush

Tuesday, September 20, 2011

Problem while deploying Agreements in B2B

You may come across a scenario wherein when you start deploying a new agreement in B2B of a trading partner which has already an agreement deployed previously, then sometimes an error comes up on your screen 

Error Message:
Thread-100: B2B - (DEBUG) oracle.tip.adapter.b2b.tpa.RepoDataAccessor:getAgreementDetails() fromTPP = TradingPartnerParticipant_DBCCtoTPP = TradingPartnerParticipant_DBCE
2009.03.18 at 05:17:17:239: Thread-100: Repository - (ERROR) Error -: AIP-11015: Object does not exist 6559DEFBDBD0B026E043C0A86365B026-298-1
at oracle.tip.repos.core.driver.CatalogDriver.getObject(CatalogDriver.java:759)
at oracle.tip.repos.core.driver.InternalObject.getAssociation(InternalObject.java:680)
at oracle.tip.repos.core.persistency.BaseObject.getAssociation(BaseObject.java:388)
at oracle.tip.model.agreement.ParticipantDeliveryChannel.getInternalChannel(ParticipantDeliveryChannel.java:212)
at oracle.tip.adapter.b2b.tpa.RepoDataAccessor.getAgreementDetails(RepoDataAccessor.java:441)
at oracle.tip.adapter.b2b.tpa.TPAProcessor.processTPA(TPAProcessor.java:587)
at oracle.tip.adapter.b2b.tpa.TPAProcessor.processIncomingTPA(TPAProcessor.java:229)
at oracle.tip.adapter.b2b.engine.Engine.processIncomingMessage(Engine.java:1715)
at oracle.tip.adapter.b2b.engine.Engine.incomingContinueProcess(Engine.java:2404)
at oracle.tip.adapter.b2b.engine.Engine.handleMessageEvent(Engine.java:2303)
at oracle.tip.adapter.b2b.engine.Engine.processEvents(Engine.java:2258)
at oracle.tip.adapter.b2b.data.MsgListener.onMessage(MsgListener.java:500)
at oracle.tip.adapter.b2b.data.MsgListener.run(MsgListener.java:348)
at java.lang.Thread.run(Thread.java:534)
at oracle.tip.adapter.b2b

So to get out of this situation, we must keep all the agreements in a single configuration i.e Only single configuration should be associated for all agreements for a Single TP
Even if you don't face this issue please note that this is a good practice to keep all agreements in a single configuration.


Cheers
Ayush




Monday, September 19, 2011

Deleting an agreement in B2B

Its quite often in development phase where you need to reconfigure an agreement which you have already validated and deployed in B2B console. Thus after undeploying the agreement when you try to delete it, B2B throws an error and doesn't allow you to do so.

Error Message on your screen :
2011.05.20 at 05:18:42:744: AJPRequestHandler-ApplicationServerThread-6: UI - (ERROR) oracle.tip.buslogic.ui.agreement.AgreementEventHandler$Delete.handleEvent(): Error -: AIP-16015: Delete of Internal Delivery Channel Usage failed with error: Cannot delete Internal Delivery Channel Usage which is referenced by Participant Delivery Channel
2011.05.20 at 05:18:42:745: AJPRequestHandler-ApplicationServerThread-6: Repository - (ERROR) Error -: AIP-11301: The MetaClass Internal Delivery Channel Usage does not have the role InternalChannel.InternalDeliveryChannelUsage
at oracle.tip.model.metadata.CatalogMetaClass.getAssociationByMember(CatalogMetaClass.java:1024)
at oracle.tip.buslogic.common.AssociationDependencyException.isSubstituteValuesChange(AssociationDependencyException.java:173)
at oracle.tip.buslogic.common.AssociationDependencyException.getMessage(AssociationDependencyException.java:213)
at oracle.tip.tools.integration.event.IPEventHandler.getExceptionMessage(IPEventHandler.java:280)
at oracle.tip.tools.integration.event.IPEventHandler.handleExceptionWithCause(IPEventHandler.java:228)
at oracle.tip.tools.integration.event.IPEventHandler.handleEventIP(IPEventHandler.java:196)
at oracle.tip.tools.integration.event.IPEventHandler.handleEvent(IPEventHandler.java:104)
at oracle.cabo.servlet.event.TableEventHandler.handleEvent(Unknown Source)
at oracle.cabo.servlet.event.TableEventHandler.handleEvent(Unknown Source)
at oracle.cabo.servlet.event.BasePageFlowEngine.handleRequest(Unknown Source)
at oracle.cabo.servlet.AbstractPageBroker.handleRequest(Unknown Source)
at oracle.cabo.servlet.ui.BaseUIPageBroker.handleRequest(Unknown Source)
at oracle.cabo.servlet.PageBrokerHandler.handleRequest(Unknown Source)
at oracle.cabo.servlet.UIXServlet.doGet(Unknown Source)
at oracle.cabo.servlet.UIXServlet.doPost(Unknown Source)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:835)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:341)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:816)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:231)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:136)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)



You need to go to the database level and delete the entry of the agreement and its dependency from the tables as it is not possible from the front end.
First of all make sure that you are not facing this issue because of low memory (please refer metalink note ID 738806.1). If issue is not with memory, then you may try to execute the below SQL's on your B2B database. 

delete from tip_internaldeliverychannelu_t;
delete from tip_participantdeliverychann_t;
delete from tip_participant_t;
delete from tip_agreement_t;
commit;

PS:- Make sure that you are NOT executing these SQL’s on a critical environment (Prod/pre-Prod).


Cheers
Ayush

Duplicate 997 EDI file names.

Scenario- Its quite obvious that for each Inbound EDI transaction received from the Trading Partner, a corresponding Functional Acknowledgement(997) needs to be sent back to the TP. In our case we had Adjustment Transaction Set (895) coming from the TP which was quite large in number(traffic wise) and so the 997s also became quite large in number.

Problem- There were some cases where the outgoing 997 files were being created with the same file name by B2B when they are generated at the same moment of time.Thus the TPs were missing some 997s as B2B was overwriting the file with the same name.The outgoing file name format was ("%FROM_PARTY%_%TIMESTAMP%.dat") .

Cause- There was no direct cause to find the reason as why B2B was behaving in such an abnormal way as the 997 was automatically initiated by B2B as soon as it received the inbound file.
PS: Make sure that MLR #15 or later version patch is already applied on your B2B server. If not then kindly apply the same and then check.

Solution-Definitely problem was with the time resolution. If resolution is not in nano-seconds then such problems may occur under heavy load. Oracle B2B internally uses JAVA API's for creating time-stamp and if OS does not have nano second time resolution then time-stamp may not be unique.
To remove the discrepancy of time format in the filename, i made the name unique by using Message ID ("%MSG_ID%") in the file name and prblem was solved.

You can also use InReply to Message ID ("%INREPLYTO_ID%") in filename format to keep it unique.

Happy learning!!



Cheers
Ayush