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

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

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